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Dariptas delectat 


A változatosság gyönyörködtet 


De mire utal a cím, ez a latin mondás? Novemberi felmérésünk azt mutatja, hogy a bevált ro- 
vatok mellett új témaköröket is szívesen olvasnának. Ez a szokatlan vezércikk felvillant néhány 
olyan témakört, melyekkel 2003-ban foglalkozni szeretnénk. 

Ha erőnk, kapacitásunk engedi. Az én fejemben például vagy hat rovat terve áll készen arra, 
hogy papírra vessem. Az igazság az, hogy némelyik rovatom már másfél éve vár, egyre csak 
vár, hogy papírra kerüljön. 
A latin mondás teljeskörű beváltásához sok-sok, különböző világlátású szerző munkájára len- 
ne szükség! Írjanak nekünk! 





Horizontális és vertikális vezérfonalak 


Szeretnénk megkönnyíteni azok döntését, akik megfelelő tudással és elegendő bátorsággal ren- 
delkeznek ahhoz, hogy a többi olvasónak átadják saját tudásukat. Közel fél évre előre tudjuk, 
hogy az egyes hónapokban mi lesz a vezérmotívum. Ezek felsorolását horizontális vezérfonal- 
nak nevezném, ami segít meghatározni, hogy mikor milyen témában várjuk az Önök értékes 
tapasztalatát. Íme 2003 első fél éve, címszavakban: 


H SOL Server. A jelenlegi számban az SOL Server a vezérfonal, vagy négy cikk foglalko- 
zik SOL-alapú technológiával. SOL a Windows CE-n, hackertámadás SOL Server ellen, 
SOL-adatbázisok replikációja várja a Kedves Olvasót. Az SOL-technológia végtelen 
volta miatt távolról sem mondhatjuk, hogy ez a vezérmotívum ezennel lerágott csont- 
tá vált. Ha valaki késztetést érez, írhat még az SOL-nyelvről magáról, a Profilerről, az 
SOL Server rendszergazdai feladatairól, a fontosabb tárolt eljárásokról, a kurzorokról, a 
különböző varázslók (pl. webtask) tucatjairól. 

HA Exchange Server, Titanium, levelezés. Ennek a vezérfonalnak az ad aktualitást, hogy ki- 
múlóban van az Exchenge 2000 Server. Verzióváltás elé nézünk, ilyenkor mindig érde- 
mes körülnézni az új termék háza táján, vajon érdemes-e váltani? 

HA Windows 2003 Server (Volt . NET Server). Ez az új operációs rendszer annyit késik (most 
áprilisra ígérik), hogy már lassan mindent megírtunk róla, így csak tízezer kiaknázatlan 
lehetőségünk maradt. Csak az Active Directory területéről néhány újdonság: tartomá- 
nyok átnevezése, AD-telepítés CD-ről replikálva, Universal Group-gyorstár (GC-men- 
tes bejelentkezés!), felhasználói AD-partíciók, Resultant Set of Policy (RSoP), VVMI- 
szűrők a Group Policyban stb. Ezekről a dolgokról nem lehet rutinból írni, mert ma még 
senkinek sincs elegendő mennyiségű Windows 2003 gyakorlata. Aki nekünk ezen té- 
mák papírra vetésében segít, mellesleg hatalmas mennyiségű ismeretanyagot is megta- 
nul, s bejut az Informatikus Paradicsomba! 

A Rendszerfelügyeleti technológiák a Microsoft és más gyártók , tollából". Csoportos há- 
zirend, MOM, SMS, külső gyártók életminőség-javító eszközei (pl. Hyena). 

A Rendelkezésre állás, hibaelhárítás, teljesítménynövelés. Ha ezt a témakört minden ter- 
mékre kiterjesztjük, a lehetséges témaköröket végiggondoljuk, 200 oldal alatt meg sem 
állunk. Ismétcsak: vállakozót keresünk a saját erőnkön felüli 160 oldal megírására! 

JA Rendszerbevezetés az alapinfrastruktúrától az elosztott alkalmazásokig. Egyszer össze 
kellene már foglalni, mi is szükséges egy informatikai hálózat kialakításához. A kábele- 
zés nem a mi területünk, de az IP-cím kiosztás, a DNS-, DHCP-, WINS-infrastruktúra 
igen. A tartománytervezés igen. A vállalati  webalkalmazás telepítésének és üzemelteté- 
sének feladatai igen. 

A Biztonságos Internetezés. Ebben a témakörben az ISA Serverre támaszkodnánk. Remél- 
hetőleg a közeljövőben megjelenik a novemberre ígért ISA Feature Pack, benne az 
RPC-filter, SPAM-filter, OWA-publikációs varázsló, és a tűzfalra telepíthető URLScan. 


tése ff EAT. 41 


Amire vágyunk: tapasztalatok átadása. Egyféle tapasztalat-hal- 
mazzal persze mi magunk is rendelkezünk, de nem hisszük, 
hogy a világ összes érdekes, esetleg kényes témakörébe bele- 
futottunk mindennapi munkánk során. A levelezési listákon 
évek óta élvezhetjük a ,több szem többet lát" módszer előnye- 
it, de ott — érthető okokból — nem igazán kerül sor egy-egy 
probléma alapos körüljárására. A tech.net magazin erre ad le- 
hetőséget! 


A másik vezérfonal-típus az általunk régóta tervezett, de 
erőforrás hiányában soha ki nem vitelezett rovatok tartalom- 
mal való megtöltése. Ezeket nevezem vertikális vezérfonalak- 
nak. Némelyik rovat nagy ritkán kap egy-egy cikket, de ezek a 
területek jobbára lefedetlennek mondhatók: 


TA A Windows szolgáltatásai A-tól Z-ig. A Felügyeleti esz- 
közök szolgáltatások alatt megjelenő szolgáltatások 
ismertetése. Melyik mire való, melyiket lehet bátran le- 
állítani, melyik létfontosságú. A Windows XP már tar- 
talmaz néhány soros szolgáltatásleírásokat, de ettől 
még nem fogjuk átlátni, ki kivel van, melyik mire való. 
Példaként itt a BITS igen beszédes magyarázata: 


Ká Művelet Nézet Súgó FE 
5 [ES BABIR o a úm 


Background Intellgent Transfer Név / 

Service 

CB Appbcation Layer Gatevegy Service 
ED Appkcation Management 

AY ASP.NET Szate Service 
automat Updates 


A szolgáltatás izálítása 
A szolgáltatás urandtása 


leirás: 
ses ide network bandwidth to transfer 
data, 


ly Datakay s Log Service 
EaDatakey s Token Servee 


[d A szolgáltatás rövid leírása nem sok támpontot nyújt... 


TA Resource Kit-eszközök. Szép téma, hálás téma! Sereg- 
nyi iciri-piciri túlocska, (majdnem) mind hasznos esz- 
köz! A ResKit-vackok azért is nagyobb figyelmet érde- 
melnének, mert — a történelem tanúsága szerint — ezek 
előbb-utóbb beszivárognak a termékekbe. 

TA dir "osystemroot9o Nsystem32V.exe. Ez a témakör is 
szolgál meglepetésekkel. Ki tudná kapásból megmon- 
dani, melyik programmal lehet kilistázni a nyitott TCP 
portokat (netstat.exe —p tcp), teljesítménytesztnek alá- 
vetni a hálózati kapcsolatunkat (pathping.exe), el- 
lenőrizni a telepített eszközmeghajtók digitális aláírá- 
sait (sigverif.exe) stb.? Összesen 339 exe-fájl tanyázik 
ebben a könyvtárban, és nem ártana egy-két gyakorlati 
példán keresztül bemutatni, mi értelme van ezeknek? 

AA Script-sarok. Régóta tervezzük, hogy — a programozó 
rendszergazda koncepció jegyében — minden hónap- 
ban megmutatjuk egy-egy rendszerfelügyeleti problé- 
ma scripttel megvalósított megoldását. Ötletből itt sincs 
hiány: az operációs rendszer ezernyi COM-objektuma 
csak arra vár, hogy munkát adjunk neki! 

o Ezer felhasználó jelszavának (vagy bármilyen attri- 
bútumának) módosítása (ADSI) 





o Felügyeleti konzol nélküli ISA-manage- 
ment 

o E-mail küldésére képes logon script 
(CDO) 

o Mennyi szabad hely van vállalatunk PC- 
inek merevlemezén? 500 számítógépünk van, de 
SMS nincs (WMI) 

0 60-80 visszapattant levélből ki kellene bányászni a 
hibás e-mail címet, hogy a spam-adatbázist napra- 
kész állapotba hozzuk (CDO-t ADO) 

o TXT-fájl vagy Excel tábla alapján módosítást végez- 
ni adatbázisrekordokon, címtárobjektumokon 

o Stb. A lehetőségek, a feladatok és a problémák szá- 
ma korlátlan. 


MMC-modulok (dir 9osystemroot?o V.msc /s). Nyis- 
sunk egy üres felügyeleti konzolt (mmc.exe)! Hatoljunk 
le a modulok hozzáadásáig! Csodálkozzunk rá a közel 
40 darab modulra! Ezután kattintsunk az ActiveX-ve- 
zérlő nevű modulon! Döbbenjünk le a további mintegy 
60 vezérlőn, amelyek közül csak néhány betöltése ér- 
telmes, no de melyek ezek? Mondok egyet: System Mo- 
nitor Control. Ez a jószág nem más, mint a Performan- 
ce Monitor! 
NetAcademia Nagylexikon. E némiképp nagyképű el- 
nevezés egy olyan rovatot takar, melyben elmagyaráz- 
nánk egy-egy IT-fogalom mibenlétét azok számára, 
akik csak most kapcsolódnak be a Windows, vagy az 
IT-világba. Egy szócikket már kidolgoztam (T, mint tar- 
tomány), és ebbe a lapszámba beillesztettem, további 
40-50 pedig kidolgozásra vár. 
Advanced Office. Nem hiszik el, az Office mi mindent 
tud. Én elhiszem, viszont át már nem látom. Keressük 
azt a bátor vállalkozót, aki ki mer állni több ezer rend- 
szergazda társa elé megmutatni, hogy az Office rendel- 
kezik olyan képességekkel, amelyekre nekünk is szük- 
ségünk lehet. 
o Trükkös Excel-függvények 
o Az Office COM-komponenseinek képessége 
o  Scriptelt PPT-dia 
o Office Resource Kit-eszközök (meglepő módon itt, 
az ORKTools.EXE-ben találjuk a Corporate Error 
Reporting Toolt!) 
Szabványok. Ez a rovat időről időre jelentkezik ugyan, 
de gazdája nincs. Több mint 3000 RFC közül kellene 
kiválasztani azt (félltucatot, amit feltétlenül ismernie 
kell minden harcedzett rendszergazdának. A múltkori- 
ban botlottam bele a CIFS-szabványtervezetbe, ami 
nem más, mint a Windowsos SMB-protokoll (a fájl- és 
nyomtatómegosztás protokollja) szabványosításra be- 
nyújtott változata. Nosza, meg is említem a SOHO cí- 
mű cikkemben! 


Fóti Marcell 
marcellfonetacademia.net 
MCSE, MCT, MCDBA, MZ/X 


AT 2003. 01. szám 


Kicsi a bors, de erős 
SOL Server for Windows CE a gyakorlatban 


A cikk egy befejezéséhez közeledő nagyvállalati projekt tapasztalatai alapján világít rá 
azokra a módszerekre, melyek elengedhetetlenek a nagy teljesítményű, 


biztonságos, a felhasználók üzletmenetében kritikus alkalmazások feljesztésekor. 


szám / 


2003.01. 





S0L Server Accelerator for BI [5SABT] 


Relációs adatraktár, adatbetöltő 
DTS-csomagok és OLAP-kockák generálása — egy Excel 
munkafüzetből 


Az üzleti intelligencia jó dolog. Egy jól elkészített üzleti intelligencia-alkalmazás a fel- 
használók számára naprakész, interaktívan lekérdezhető információkkal szolgál a ter- 
mékek eladási jellemzőiről, az ügyfelek vásárlási szokásainak alakulásáról, a marketing- 
kampányok hatékonyságáról, a kulcsfontosságú teljesítményindikátorokról és a költsé- 
gek alakulásáról. Az üzleti intelligencia-alkalmazások egyetlen , hibája", hogy meg kell 
tervezni, és el kell készíteni őket — nem hullnak az ölünkbe. Az SSABI ezt a problémát 








Replikáció az SOL Serverben 


Az adatok elosztásának igénye sok rendszerben megjelenik, 

így nem csoda, hogy az SOL Server 2000 igen összetett 

és kifinomult infrastruktúrát biztosít az adatbázisok szerkezetének 
és tartalmának elosztására, replikálására. Cikkünkben 
fellebbentjük a fátylat a replikációról, így reméljük az írás végére 
érve új barátként üdvözlik azt. 


A http: //localhost/keress.asp?mezo-vinet - Microsoft Internet ... ( DIX! 
áj Szerkesztés Nézet Kedvencek Eszközök Súgó 
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igyekszik megoldani. 












Creöte Pubkcation Wizard 


Welcome to the Create Publication 
7 Wizard 
I. rész 


Thin vázard help you pubáth you dala so that cán be shared 
vith Subnarberz Wáh tuz wizard you wit 


9. Putlahthe dalain dötöbase Nortwind! 
9 Fiterthe data in the pubkcabon. 


9 Selthe putkcoton properbet 


Alter the pubkcation is created, tha data can be shared wih 
servert nrring SOL Server end heterogeneour dala roucer by 
credirg ndserptiont 
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JÚL injection 
Amikor elsül a kapanyél... 


Ha egy nyilvános webhelyen csak a 80-as portot találjuk nyitva, emellett a 
kiszolgálóra folyamatosan felkerülnek a legfrissebb biztonsági javítások, 
nincs más hátra, a belső hálózaton található, eldugott SOL Servert kell 
meghekkelni, mégpedig az egyetlen lehetséges bejáraton, a 80-as porton, 
a futó webalkalmazáson keresztül. , Csak" meg kell bolondítani a háttér- 
ben futó adatbázis-kiszolgálót, és tetszőleges adatokhoz hozzájuthatunk! 


HNetAcademia Nagylexikon ÜL. 


T, mint tartomány 


Napjaink nagyvállalatainál az informatika jelenléte nem is kérdéses. 
pal Az mlőr e ztás Sokan tudják, hogy egy tartomány mire való, mit tárolhatunk benne, 
ee, SG de kevesen gondolják végig, hogy miért szükségszerű a használatuk még 
ASSÁAEB abban az esetben is, ha — mint oly sok cégnél — sem adattárolási lehetősé- 
geiket, sem lekérdezhetőségüket nem használjuk ki. Ebben a szócikkben a 
tartományok (címtárak) használatát kikényszerítő belső erőket elemezzük. 


Connecting to platan 
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Hálózat a 50HO-ban 


A Windows XP kishálózatokra tervezett 








szolgáltatásai 8 
A Windows XP hálózati szolgáltatásai közt találunk jó pár olyan megoldást, me- Felhasználónév: s 
lyek igencsak megkönnyítik néhány számítógép behálózását és Internetre csat- Jelszó: e 











lakoztatását. A világ boldogabbik felén ezek a szolgáltatások az otthoni hálózat 
kialakításában segítenek — nálunk kisvállalatok vehetik hasznát! 


(JA felhasználónév és jelszó mentése a következő 
felhasználók számára 


O Csak én 


Bárki. aki ezt a számítógépet használja 


Tárcsázás: [1234567 sz] 




















ESTE e ET elet A Microsoft operációs rendszerek biztonsági 
; tényezői 

I. rész — Hová építsünk palotát? Ingoványra 
vagy kősziklára? 














Cikksorozatomban végigvezetem a Kedves Olvasót azon a hosszú 
úton, amit a Microsoft megtett, mire — néha saját korábbi technológi- 
áival is leszámolva — elérkezett arra a pontra, hogy fejlesztéseinek 
célja a világ legbiztonságosabb operációs rendszerének megalkotása 
legyen. A cég rögös, és tévedésektől sem mentes, mindazonáltal 
világosan felismerhető utat követ. Lássuk, merre jár Bill és csapata! 








Device Drivers Micro-Kernel 


























Hardware Abstraction Layer (HAL) 
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Formális módszerek az informatikában (1) 


Az előzőekben áttekintettük az UML használatát, néhány példával / A Ps 
illusztrálva azt. Remélhetűleg mindenki kedvet kapott ahhoz, P7 ) 
hogy további munkájához UML-t használjon. A továbbiakban még 4 
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- SOL Server for Windows CE a gyakorlatban / 


de erős 


Kicsi a bors, 





Kicsi a bors, Í2 erős 


SOL Server for Windows CE 


a gyakorlatban 


A cikk egy befejezéséhez közeledő nagyvállalati projekt tapasztalatai alapján világít rá azokra a mód- 
szerekre, melyek elengedhetetlenek a nagy teljesítményű, biztonságos, a felhasználók üzletmenetében 


kritikus alkalmazások feljesztésekor. 


A Microsoft Consulting Services kötelékében az elmúlt év au- 
gusztusától a Dreher Sörgyárak Rt. számára készített, Poc- 
ketPC-n futó mobil kereskedelmi adatgyűjtő rendszer tervezé- 
sén és feljesztésén dolgoztam. A rendszer magját (mind kiszol- 
gáló-, mind ügyféloldalon) SOL Server alkotta, a PocketPC ese- 
tében természetesen az SOL Server for Windows CE személyé- 
ben. Már a tervezés és a prototípus elkészítése idején számos 
megoldandó probléma merült fel. Ebben a cikkben ezekről a 
problémákról, és az általunk adott megoldásokról találhat az 
Olvasó információt. Nem célom az SOL Server for Windows 
CE dokumentációjában foglaltak megismétlése, viszont — mint 
mindig -— a dokumentáció ismerete teljesebbé teszi a képet. 


Mielőtt belevágnánk 


Az első problémát maga a PocketPC jelentette. Tisztán grafikus 
környezet, parancssor nélkül. Az általunk használt eszközök és 
módszerek jelentős része a parancssorhoz kötődik, nem is be- 
szélve a megszokás hatalmáról. 

Örömmel jelenthetem, létezik parancssor PocketPC-re, Poc- 
ketConsole néven [1]! Az alábbi ábra a konzol-meghajtót és 
benne a Microsoft CMD.EXE parancsértelmezőjét mutatja. 


(5 21:13 €3 
ja] 


Command Prompt 





A PocketConsole ablaka a benne futó Command 
Prompt alkalmazással 


Ezzel az eszközzel lehetőségünk van a repetitív fejlesztési fel- 
adatok automatizálása, illetve kis ,tesztágy" alkalmazások fut- 
tatására. 


Adatbáziskezelő a PocketPC-n 


A rendszer tervezésekor az első számú technikai szempont az 
összes adat valódi adatbáziskezelőben való tárolása volt. Ki- 
szolgálóoldalon rendelkezésre állt az SOL Server 2000, és mi 
a ,handy" (ahogy a PocketPC-t a csapaton belül neveztük) ol- 
dalon is hasonló eszközt szerettünk volna. A feljesztői környe- 
zet, amelybe a kiválaszott eszköznek illeszkednie kellett, natív 
C-t volt, a PocketPC szűkös erőforrásainak minél jobb kihasz- 
nálása érdekében. Igaz, egy kevés munkát spóroltunk a Micro- 
soft Foundation Classes (MFC) használatával. Kívánalmaink- 
nak a három jelölt közül (Windows CE saját adatbázisok, SOL 
Server CE, XML fájlok) közül legjobban az SOL CE [2] felelt 
meg, így egy rövid prototípuskészítési időszak után le is tettük 
mellette a voksot. 

A kiszolgáló és a handy-k közötti kommunikációs csatornaként 
az SOL CE replikációs motorját kívántuk használni. (Az SOL- 
replikációrval jelen lapszámunk 13. oldalán kezdődő cikkben 
foglalkozunk bővebben!) 

A feljesztés során a következő szakaszokban tárgyalt öt problé- 
ma merült fel. Ezek mindegyikére adott jó megoldás jelentősen 
emelte az elkészült rendszer minőségét. 


Biztonságos infrastruktúra 


Az SOLCE replikációs motorja két komponensből áll. Kiszolgá- 
lóoldalon egy ISAPI DLL figyeli a beérkező kéréseket, illetve 
továbbítja azokat a megfelelő SOL Server 2000 kiszolgáló felé. 
Handy-oldalon egy COM-objektum végzi el a kiszolgáló felé 
küldött HTTP-kérések összeállítását, majd az azokra kapott vá- 
laszok helyi adatbázisba való elhelyezését. Hogyan tudjuk biz- 
tosítani a handy-k felhasználóinak azonosítását, és az adatfor- 
galom titkosítását? 


HTTPS - lenne az egy szavas válasz. A helyes megoldás felé 
vezető első gondolat valóban ez, ám két részproblémát kell 
még megoldani: egyrészt a handy-t képessé kell tenni az álta- 
lunk kiadott tanúsítványok elfogadására, másrészt megfelelően 
el kell helyeznünk a kiszolgálóoldali ,dobozokat". 

Kezdjük a második feladattal, az egyszerűbb. A kétféle le- 
hetőség közül (egy kiszolgálón futtatott SOL és IIS, avagy két 
külön kiszolgálón futtatott SOL és IIS) mi a két kiszolgálós meg- 
oldás mellett döntöttünk, üzemeltetési és teljesítmény-okok 
miatt. Ebben az esetben viszont csak , basic / clear text" azo- 
nosítás használható a felhasználók kilétének ellenőrzésére, 
ami a HTTPS-t még égetőbbé teszi. 


A handy alapértelmezés szerint csak egy maroknyi, beégetett 
tanúsító hivatal által kiadott tanúsítványt tud elfogadni. Ha más 


(mondjuk saját) tanúsító hivatal adta ki a webkiszolgálónk ta- 
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núsítványát, a handy-n megbukik az ellenőrzés. Azonban az 
SOL CE-hez jár egy kis programocska, amely segítségével új ta- 
núsító hivatalok tanúsítványait is behegeszthetjük a gépre. Ez 
nemcsak SOL CE esetén hasznos! A program a következő for- 
mában használható: 


ROOTCERT [tanúsítvány.CER] 


Ha nem adunk meg tanúsítványt, automatikusan a gyökér- 
könyvtárban található ROOTCERT.CER állományt keresi. 


Adattípusok 


Már a központi adatbázis kialakításánál figyelembe kellett ven- 
ni az SOL CE által ismert adattípusokat. A maximális oszlop- 
szélesség metaadatokkal együtt 4KB, azaz mintegy 3800 bájt- 
nál szélesebb sorokat ne nagyon csináljunk! Ettől szélesebb so- 
rokat is készíthetünk NVARCHAR vagy VARBINAÁRY típusok- 
ból, azonban ha a tényleges adatszélesség meghaladja a 4KB- 
ot, a beszúrás vagy frissítés nem fog lefutni. 
Karakterkészlet-konverziós problémáink nem lesznek, mivel 
az SOL CE csak Unicode karakterláncokat kezel (NCHAR és 
NVARCHAKR) típusok. Ez egyrészről kiküszöböli az összes kód- 
lapokkal és konverzióval kapcsolatos problémát, másrész vi- 
szont az amúgy is szűkös oszlopszélesség miatt pazarlásnak 
tűnhet. Azokban az esetekben, amikor biztosan tudjuk egy ka- 
rakterláncról, hogy nem tartalmaz csak ASCII karaktereket, cél- 
szerű a karakteres adattípusok helyett binárist használni (VAR- 
BINARY). A handy-n ezt az adatelérési rétegben, a központi ki- 
szolgálón pedig tárolt eljárások alá tudjuk elrejteni. 

A következő megszorítás előtt egy kis kitérő. Mivel C--4- kör- 
nyezetben dolgoztunk, kétféle adatelérési módszer közül vá- 
laszthattunk. A kényelmesebb ADOCE illetve a pucér OLEDB 
között. Sajnos az ADOCE használata nem javasolt C-4-4- prog- 
ramokból, így maradt az OLEDB. Az első fordítás alkalmával 
azonban úgy tűnt, mintha az OLEDB fájlokra fittyet hányna a 
rendszer. Az ok a WCE.H fájlban gyökerezik. Idézem: 


7/ Prune unsupported MFC/OS headers 


tdefine . docobjh 
tdefine ,. oledb h 


// itt a baj 

Míg a ,normál" PC-s MFC támogatja az OLEDB használatát, a 
PocketPC-s verzió esetén ez teljesen hiányzik, sőt, meg is pró- 
bálják akadályozni annak használatát (ám kis munkával ez 
korrigálható). 

A probléma részben egyetlen sorral gyógyítható volt, ahogy azt 
a következő kódrészleten láthatjuk. 


tinclude cafx.h: 
tinclude cafxext.h: 


$tundef . oledbh 


tinclude coledb.h: 
tinclude coledberr.h: 


Azért csak , részben", mert ezek után el kellett készíteni a saját 
mini ADO-nkat, a nagy testvér számos tulajdonságával. 

A handy szűkös memóriája miatt az adatbázisok kialakításánál 
hajlamos az ember a megfelelőnek ítélt helyeken SMALLINT és 
TINYINT típusok használatára. Azonban az SOL CE-hez tarto- 
zó OLEDB szolgáltató egyik típusú oszlop tartalmát sem tudta 
visszaadni, egyik esetben sem tudja elvégezni a natív adattípu- 
sok és az adatbázisbeli adattípusok megfeleltetését. Ugyanaz a 


kódrészlet a nagy SOL Server esetében kifogástalanul e 
működik. A SMALLINT típusú oszlopok konvertálha- mil 
tók INT-re (lásd a következő kódrészletet), a TINYINT 


azonban így sem működőképes. 


SELECT CustomerId, CONVERT (ZipCode, INT) FROM 
5 customers 


Konklúzió: ne használjuk TINYINT-et, és a SMALLINT oszlo- 
pokat konvertálnunk kell INT-té. 


Konkurrens hozzáférés 


Az SOL CE adatbázisai egyfelhasználósak, azaz egy-egy fájlt 
csak egyetlen alkalmazás nyithat meg (ennek kikényszerítésé- 
re exkluzív zárolja is a fájlokat). Ez abban az esetben jelent 
problémát, amikor a replikációt végző COM-objektum is meg 
akarja nyitni — az alkalmazás által már nyitva tartott — fájlt. A 
replikáció tehát nem végezhető el háttérfeladatként. 

Az alkalmazás adatelérési rétegében a replickáció elindítása 
előtt le kell zárnunk az adatbáziskapcsolatot, majd a replikáció 
befejezése után újra megnyitni azt. Ezzel a megoldással ma- 
gasabban lévő rétegek számára teljesen transzparens módon 
kikerülhető ez a fájdalmas pont. 

A ,zárolós" viselkedés egy nagyon hasznosnak bizonyult diag- 
nosztizálási eljárást tett lehetővé. Ha ugyanis valamelyik üzle- 
ti logikai objektum nem engedte el az általa használt adatbá- 
zisobjektumokat, a kapcsolat lezárásánál és a szinkronizálás- 
nál erre azonnal fény derült (nem kellett hosszú órákat tölteni 
memóralyukak keresésével). 

Érdemes odafigyelni fejlesztés közben arra is, hogy ne hagyjuk 
nyitva az adatbázisunkat Ouery Analyzerben. Perceket lehet 
ekkor tölteni a megnyitási hiba okának keresésével... 


Replikáció 

Lévén a handy-alkalmazás mobiltelefonon keresztül tartja a 
kapcsolatot a központi SOL kiszolgálóval, nem elhanyagolha- 
tó szempont a replikációs adatforgalom mennyisége. 

Annak biztosítására, hogy minden egyes handy csak azokat az 
adatokat kapja meg, melyre ténylegesen szüksége van, szűr- 
nünk kell a replikáció során. Az SOL CE a nagy testvéréhez ha- 
sonlóan támogatja a HOST NAME replikációs paramétert. 
Minden handy-nek egyedi nevet adva a replikációs folyamat 
során a szűrés már elvégezhető. 


Teljesítményt ide! 


Az alkalmazás korai változataiban még az SOL CE 1.1-es ver- 
zióját használtuk, majd megjelenésekor áttértünk a 2.0-ra. A 
kezdeti kód az 1.1 lehetőségeihez mérten készült, azonban si- 
ralmasan lassúnak bizonyult. A rövid válaszidők rendkívül fon- 
tosak egy interaktív alkalmazás felhasználójának, így körülbe- 
lül egy nagyságrenddel kellett felgyorsítani a kód adatbázissal 
foglalkozó részét! 
Kiindulási pontként az alkalmazás profiler alatti futtatásából 
származó statiszkai adatok, illetve az MSDN-en található rend- 
kívül részletes és jó cikk [3] szolgált..-A részletes analízis három 
pontot jelölt meg, mint a teljesítményproblémák okát. Ezek a 
következők voltak: 
JA Karakterlánc-műveletek (CString::Format és az sprintf 
valamint rokonai). 
HA Az SOL-kifejezések állandó újrafordítása. 
A Olyan adatok betöltése, melyekre csak később lesz 
szükség (ha egyáltalán szükség lesz). 


"$IOg RO ISIIK / 


p 


. §0Ia a 


úegjelioyeÁS e 3] smopuim 10 1an135 105 


- 7] 
ma 7 
-— 


- SOL Server for Windows CE a gyakorlatban / 


de erős 


Kicsi a bors, 


Nem meglepő, hogy a karakterlánc-műveletek drá- 
gák, azonban a PocketPC esetén ez sokkal élesebben 
(egy nagyságrend) jelentkezik, mint PC-k esetén. A 
karakterlánc-műveleteket a lekérdezések összeállítá- 
sára használtuk. (Az SOL CE 1.1-ben nem létező pa- 
raméterezett lekérdezések miatt. Így nem is használhattunk pa- 
raméterezett lekérdezést, ami állandó újrafordításokat eredmé- 
nyezett.) 

Az SOL CE 2.0 már lehetővé teszi paraméterezett lekérdezések 
használatát, a karakterláncok másolgatását ezzel ki lehet válta- 
ni. Viszont az állandó újrafordítások ellen ez sem véd. [3] em- 
lítést tesz róla, hogy a lekérdezési tervek mindaddig nem kerül- 
nek újrafordításra, amíg a OLEDB Command-objektumot nem 
szabadítjuk fel. Ezzel lehetővé válik a lekérdezési tervek újra- 
hasznosítása. 

Kezdetben minden egyes adatelérési osztály metódushívásnál 
elkészítettünk egy Command-objektumot, elvégeztük a műve- 
letet, majd felszabadítottuk az objektumot — eldobva ezzel a 
lekérdezési tervet. Az sem nyújtott kielégítő megoldást, ha az 
egyes adatelérési osztályok példányainak élettartama alatt 
megtartottuk a Command-objektumokat, mivel az adatbázis- 
osztályokat használó űrlapmegjelenítő gráf nagy számban hoz- 
ta őket létre. (Megj.: Az űrlapmegjelenítő gráf alkotja az alkal- 
mazás magját, ennek funkcióihoz kellett illesztenünk az adate- 
lérési réteget, fordított irányú illesztés nem kivitelezhető. Az 
űrlapmegjelenítő motor bővebb ismeretetése túlmutat a cikk 
keretein.) 

Ezt az elérési mintázatot figyelembe véve adódik az egyes 
adatbázisműveletekhez tartozó Command-objektumok stati- 
kus változókban való elhelyezése. A megoldás előnye, hogy ha 
egyetlen példány elkészítette a Command-objektumot, ezáltal 
a lekérdezési tervet, a későbbiekben létrejövő példányoknak 
ezt a feladatot már nem kell elvégezniük — csak megadják a pa- 
raméterek aktuális értékét, és mehet is a lekérdezés. Figyeljünk 
oda arra, hogy minden egyes lekérdezéshez külön Command- 
objektum tartozik, nem csak egyetlen darab van osztályonként 
(következő ábra)! A megoldás alkalmazásával nyolcszorosára 
gyorsult az alkalmazás adatelérési kódja! 


Ügyfélosztály 
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E Statikus Command-objektumok az adatelérési osztá- 
lyokban 


A harmadik teljesítményproblémára az űrlapmegjelenítési gráf 
használata könnyen kivitelezhető megoldást adott: a gráf inici- 
alizálásakor csak azokat az ágakat töltjük be, melyek láthatók. 
Ezen egyszerű optimalizálással és a statikus Command-objek- 
tumok használatával több mint hatvanszoros (60!) válaszidő- 
csökkenést értünk el. 


Konklúzió 


A SOL Server CE méretéhez (és a gép méretéhez, amin fut) ké- 
pest jól használható, kellemes eszköz. A felmerült problémák 
azt mutatják, hogy nem lehet csak úgy , durrbele" módon hasz- 
nálni, oda kell figyelni arra, mit csinál az ember. A szubopti- 
mális megoldások, melyeket a PC-s világban esetleg elfed a vas 
nyers ereje, a handy világában nem hoznak eredményt. 


Pusztai László 

laszlopamicrosoft.com 

A szerző a Microsoft Magyarország vezető tanácsadója 
MCSE, MCSD 


A cikkben szereplő URL 


(11 http:/Awww.symbolictools.de 

12] http:/Awww.microsoft.com/sgl/CE/default.asp 

(3] http://www.microsoft.com/technet/prodtechnol/sgl/ 
maintain/Optimize/SSCEGPOP.asp. 
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Relációs adatraktár, adatbetöltő DTS- 
csomagok és OLAP-kockák generálása — egy 


Excel munkafüzetből 


Az üzleti intelligencia jó dolog. Egy jól elkészített üzleti intelligencia-alkalmazás a felhasználók szá- 
mára naprakész, interaktívan lekérdezhető információkkal szolgál a termékek eladási jellemzőiről, az 
ügyfelek vásárlási szokásainak alakulásáról, a marketingkampányok hatékonyságáról, a kulcsfontossá- 
gú teljesítményindikátorokról és a költségek alakulásáról. Az üzleti intelligencia-alkalmazások egyet- 
len ,hibája", hogy meg kell tervezni, és el kell készíteni őket — nem hullnak az ölünkbe. Az SSABI ezt 


a problémát igyekszik megoldani. 


Az SOL Server 7.0 megjelenése óta a Microsoft folyamatosan 
törekszik az adatraktárkezelési és OLAP- (On-Line Analytical 
Processing) technológiák fejlesztésére, az üzleti intelligencia 
alkalmazások elterjesztésére. Az SOL Server része a DTS (Da- 
ta Transformation Services) és az Analysis Services (OLAP-ki- 
szolgáló) is. A relációs adatbázisokat, a DTS-csomagokat és az 
OLAP-kockákat hatékony grafikus felületeken tervezhetjük, 
vagy különböző parancsnyelveken írt programokkal generál- 
hatjuk, de egy adatraktár kialakítása a legjobb eszközökkel is 
sok munkával jár. 

Ugyanakkor az évek során az alkalmazástervezők és -fejlesz- 
tők megtanulták, milyen részekből áll egy-egy típusalkalma- 
zás, milyen relációs és OLAP-adatbázisokat célszerű kialakíta- 
ni, és hogyan célszerű ezeket adatokkal feltölteni. Az SSABI er- 
re a tudásra épül. 


Az SSABI részei 


Egy RAD (Rapid Application Development) eszköz, két előre 
elkészített adatmodell, ötszáz oldal dokumentáció és különbö- 
ző segédprogramok. 


Az Analytics Builder — RAD eszköz 


Felhasználói felülete az Analytics Builder Workbook, egy Excel 
fájl, amelyben leírhatjuk a kialakítani kívánt alkalmazást. Ez az 
Excel munkafüzet indítja az alkalmazásgenerátort, ami az üz- 
leti intelligencia alkalmazás nagy részét automatikusan gene- 
rálja. Ezek a következők: 

HA az előkészítő (staging) adatbázis; 

HA a vizsgált adatokat tartalmazó (subject matter) relációs 
adatraktár; 

HA OLAP-kockák; 

HA a fentieket feltöltő és karbantartó DTS (Data Transforma- 
tion Services) csomagok; 

A és a kliensoldali nézetek, amelyekkel az OLAP-kocká- 
kat elérhetjük. (/lelenleg csak a ProClarity Analytic Plat- 
formhoz van kliens generátor, és csak az SMA adatmo- 
dellhez sablonok.) 


A generált elemeket a következő ábra szemlélteti: 








Az SSABI által generált alkalmazás három logikai szerepkörből 
áll: 

TA A Microsoft Business Intelligence (MSB/) Server, ahol a 
DTS-csomagok futnak; 

HA A relációs kiszolgáló, amely a BisoCatalog adatbázis, to- 
vábbá az előkészítő (Staging) és a vizsgált adatokat tar- 
talmazó (Subject Matter) adatbázisok találhatók; 

HA Az Analysis Server, az OLAP-kockák tárolója. 


(Fejlesztéskor a relációs és az MSBI szerepek kötelezően egy 
gépen vannak.) 


Adatmodellek 


A ,Retail Analytics" (kereskedelmi analízis) és a ,Sales and 
Marketing Analytics" (eladási és marketinganalízis) két alkal- 
mazástípus előre elkészített modellje. Ezeket a konzulensek, 
tervezők, fejlesztők az adott ügyfél igényei szerint testreszab- 
hatják. 


Dokumentáció 


Útmutatók (Prescriptive Architecture Guides,.PAG), amelyek 
részletesen ismertetik az üzleti intelligencia alkalmazások fej- 
lesztését, telepítését, karbantartását. Ezek a dokumentumok fej- 
lesztők, konzulensek és partner cégek tapasztalataira épülnek, 
és a ,legjobb gyakorlati megoldásokat" igyekeznek átadni az 
új alkalmazások tervezőinek. (Vigyázat! Ha valaki a [3] webol- 
dalról próbálja letölteni a PAG-ot, csak egy-két fejezethez jut. 
A teljes PAG csak az SSABI telepítése után érhető el!) 
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Letöltés, telepítés 


A [3] weboldalról elindulva, regisztráció után, letölt- 
hetjük az SOLBIAccelerator(english).exe fájlt. Ez egy 
kb. 24 MB-os, önkibontó exe. Kibontás után a telepí- 
tés a setup futtatásával történhet. Telepítés előtt java- 
solt elolvasni a ,readme", a , Dev 1 Overview" és a , Dev 2 Ins- 
tallation" dokumentumokat. 


A telepítés technikai feltételei 


TA Windows 2000 -- SP2, vagy Windows XP Professional 

HA SOL Server 2000 Enterprise, vagy Developer Edition 

HASOL Server 2000 SP2 és SOL Server 2000 Analysis Ser- 
vices SP2 

HA Windows Scripting Host v. 5.6 (az Internet Explorer 6.0 
ezt a verziót tartalmazza). 

TA Office XP (Excel és Word) 4- SP1 


Szükséges továbbá, hogy az SOL Server 2000 és az Analysis 
Services 2000 fussanak a telepítés indítása előtt. 


A telepítés után 


Az SOL Serveren a telepítő létrehoz egy BisoCatalog nevű adat- 
bázist, amely az alkalmazásgenerátor működését támogatja. 
Az SSABI fájljai alapértelmezésben a következő mappába ke- 
rülnek: 


C:XProgram FileslMicrosoft SOL Server Accelerator 
TONAGI 


A Start menüben megjelenik a ,Microsoft SOL Server Accele- 
rator for BI" csoport, alatta az , Applications", a , Guides", és a 
a Tools" csoportok, illetve egy mutató a ,Release Notes"-ra. 
Az , Applications" csoportban a megszokott értelemben vett al- 
kalmazást hiába keresünk. Itt a két előre elkészített adatmodell, 
a ,Retail Analytics" és a , Sales and Marketing Analytics" mun- 
kafüzeteit és az adatmodellek leírását találjuk. 


Ismerkedés a termékkel 


Elsőre valószínűleg mindenki az egyik kész alkalmazás Excel 
munkafüzetét fogja megnyitni, de ha valaki saját tervet szeretne 
készíteni, a ,tools" mappában található , AnalyticsBuilder- 
WB. Empty.xls" munkafüzetet használhatja. A ,tools" mappa tar- 
talmazza a segédprogramokat és egyéb hasznos apróságokat is. 
A munkafüzet megnyitásakor engedélyeznünk kell a makrók 
futását — legalábbis, ha érdemben használni akarjuk a szolgál- 
tatásait. 
A munkafüzet a következő lapokból áll: 

Me LEtET (árért) 

Overview Áttekintés, általános tippek 

a használathoz. 

DBs Az elkészítendő adatbázisok neveinek 
és helyének meghatározása 
A generált idődimenzió és hierarchiák 
jellemzőinek megadása 
Dimensions A többi dimenzió és hierarchiáik 
Levels — Hierarchiaszintek — 
PropertiesV/Dims  Tagtulajdonságok és virtuális dimenziók 








Autogen Time 





























. pCubes Fizikai kockák 
pMeasures Fizikai mértékek ki 
vCubes Virtuális kockák 
CalcMembers Számított tagok ga 
. NamedSets Nevesített halmazok 
CalcCells Számított cellák 














Actions Akciók 
Mappings Leképezések a sablon és a testreszabott 
modell megnevezései között 
a jelentésgenerátorok számára 
Processing Az alkalmazásgenerátor indítása 





Az ABW (Analytics Builder Work- 
book) eszköztár funkciói: sor be- 
szúrása, sor törlése, az aktuális lap 
ellenőrzése, az össze lap ellenőrzése és segítségkérés. Ha egy 
modellt készítünk, jó gyakorlat az aktuális lap ellenőrzése, mi- 
előtt továbblépnénk. 

A következőkben néhány fontos munkalapot nézünk meg. 
A ,DBSs" lapon az , Analysis Server Name" az OLAP-kiszolgá- 
lót futtató gép neve, míg az ,MSBI Server Name" az SOL 
Server gép nevét adja meg. (Jelenleg az SSABI csak default 
instance-szel dolgozik.) Alapértelmezésben mindkettő a helyi 
gépre mutat. Ha az MSBI (Microsoft Business Intelligence) 
szervernek nem a lokális gépet választjuk, a megadott gépen is 
telepítenünk kell az SSABI-t. Az Analysis és a Subject Matter 
adatbázisok neve azonos kell, hogy legyen, különben később 
a generálás hibát jelez. 


azt 


MSBI Server name 
Analysis database name RA01 


Subject Matter database name RAD1 
Analysis database label Generic schema, Mict 
Application name for client templates 
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Az , AutogenTime" lap az idődimenziót írja le: 


Calendar Start: 11997.01.01 
Calendar End: 1200 
Time dimension language: English; Engiisk 


Standard 
z 





Hierarchy 

Include in database? 

First Day of Week 

First Month of Year 

First Day of Month 

First Week of Month 

Which Ouarter has extra period? 

Marketing calendar pattern 

Day of year 

Day of guarter 

Day of month or period 

Day of week 

Week of year 

Week of guarter 

Week of month or period Í 
Month or Period of year ! 


Month or Period of guarter 
Ouarter of year y 
ü £DBs ) ü 1f 





ajaj ed ala 





SUNp Jena opnipuj 


aa 








Az idődimenzió különböző hierarchiákban vizsgálható. Bár a 
fenti képen nem látszik, a standard mellett van pénzügyi, 
marketing és gyártási hierarchia is. Az idődimenzió nyelvét 
egy listából választhatjuk, amely kezdetben a magyar nyelvet 
nem tartalmazza — ezzel a problémával a cikk végén foglal- 
kozom. 

A Dimensions lapon fontos a változó dimenziók kezelése. A 
Track history" a változások követését jelenti, azaz ha például 
egy ügyfél másik városba költözik, megőrizzük az eredeti sorát 
a dimenziótáblában, és — az új címnek megfelelően — egy 
újabb sor keletkezik. Ha ,Restate history"-t, vagyis az adatok 
átírását választanánk, az ügyfél korábbi vásárlásai hirtelen egy 
másik városba kerülnének, vagyis meghamisítanánk az eladá- 
sok területi eloszlását. 

A ,Restate history seldom" esetén egyszerűen aktualizáljuk a 
dimenzió adatait az adatraktárban és az OLAP-adatbázisban. 
,Restate history often" esetén ezen felül, a dimenziót változó- 
nak deklaráljuk az OLAP-adatbázisban. Hierarchikus, illetve 
sík dimenziók esetén csak egyféle ,Restate history" van. 







Product ———— Standard 7 
[oszze tt asstMátkátögeez Sa 


 Farocast Sonar Tőtandarú 


Standard 














seldor 
seldor 










seldor 


A PropertiesVDims oldalon a dimenziótagok , tulajdonságait" 
adhatjuk meg, illetve hogy ezek közül melyikből készüljön vir- 
tuális dimenzió: 













ls Virtual 
Dim? 


Member Property 
Dimension-Hierarchy [Name 

Iezszés e EKE DRHETOME etatússs a Si 
ez Ae VEZE EÍMANSTŰS Szet 
ENEKEL - [ELT Áá ss] 
[ez ds séta ZSM MENESŐSTEs szd 
[eti c ss sttpag SES GÖNRBTATEBNSÓ 
[eti ze áz teát ását 
BEÜT TSZ: d 
KÉGBEKÉZHÉSÜT SE -i 
[egét e ZMESZNRNKÉ SES] 












End Offering Date 
[Mode s szt] 
UPC Code 


A virtuális dimenziók a klienseszközökben és az MDX-lekérde- 
zésekben ugyanúgy használhatók, mint a ,rendes" fizikai di- 
menziók, ugyanakkor az OLAP-kocka méretét nem növelik 
meg, mivel ezekhez aggregátumok nem képződnek. Ebből kö- 
vetkezően a kocka feldolgozási idejét sem növelik. Megnőhet 
viszont a lekérdezések végrehajtási ideje — éppen az aggregá- 
tumok hiánya miatt. 


Említést érdemel a pCubes oldalon a , Partition by Month" osz- 
lop. Nagy tömegű tényadatot tartalmazó kockák esetén az idő 


NET WÉtET ag wa 


szerinti partícionálás jelentősen javítja mind a feldolgozás, 
mind a lekérdezések végrehajtási idejét. 
A munkafüzet utolsó oldala a legizgalmasabb: 


Options for the script to load data: 
F Copy sample data files to import directory from:  IflnstallDir] 
Set "current day" in cube to this date: 1.12.31 
F Execute load script 


DTS package options: 
et default DTS nacka 





A , Generate Application" gombbal indíthatjuk az alkalmazás- 
gyártást. Ha a , Copy sample data..." pipát bekapcsoljuk, teszt- 
adataink is lesznek. (A tesztadatok beolvasása folyamán meg- 
jelenő DOS ablakot ne lőjük le. Erre egyébként a , still proces- 
sing..." üzenet is figyelmeztet. Az ablak magától bezárul, ha a 
DTS-csomagok futtatása befejeződött.) 


A generálás eredménye 

Fájlok, mappák, DTS-csomagok, két relációs adatbázis és egy 
OLAP-adatbázis készül. (Az RA modell nem tartalmaz kliens- 
nézetet generáló sablont.) 

Az RA01 OLAP-adatbázis 


Az adatbázisobjektumokat az Analysis Managerrel vizsgálhat- 
juk. (Az ábrán nem minden dimenzió látszik!) 


éj RA01 
£-Cd Data Sources 








6-9 Direct Sale 

H1-C Forecast 

CI Inventory 

I Item Sale k 

e Sales Planning 

5-3 Shared Dimensions 

; Hz Campaian.Standard 

2 Cashier.Cashier 

aZ; Channel.Standard 

:.H Customer Type.Standard Geog 
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Az adatbázis forrása az RAO1 relációs adatraktár. 
Négy fizikai és egy virtuális kockát tartalmaz. A Sales 
Planning (Eladástervezés) virtuális kocka az Item Sale 
(Bolti Eladások), a Direct Sale (Egyéb Eladások) és a 
Forecast (Előrejelzés) kockákból áll. Ha a dimenzió-, 
illetve a kockaszerkesztővel megnézzük az adatbázis elemeit, 
pontosan a munkafüzetben előírtakat látjuk megvalósítva. 
Érdekesség, hogy az adatkockák nincsenek optimalizálva a 
feldolgozás szempontjából. A fejlesztés ideje alatt ez lényeg- 
telen. Telepítés előtt a kockaszerkesztőben, a Tools menü Op- 
timize Schema parancsával célszerű a séma optimalizálását 
elvégezni. 


Az RAO1 relációs adatraktár 

Táblák 

A Subject Matter adatbázis dimenzió- és ténytáblákat tartal- 
maz. Az adatbázis szerkezete ,hópehelyséma", tehát minden 
dimenziószint külön táblába kerül. 

Minden dimenziótábla a forrásoszlopok mellett tartalmaz 
olyan metaadatokat, amelyek a betöltő DTS-csomagok munká- 
ját segítik. Az OLAP-kockában opcionálisan használható , cus- 
tom sort order", , custom rollup", "custom member options" és 
,Custom unary operator" számára szintén készül egy-egy osz- 
lop. Minden dimenziótáblában van egy sor az , ismeretlen" ta- 
gok számára — így minden tény sor illeszkedni fog egy dimen- 
zió taghoz, nem eshetnek ki sorok az OLAP-kockák feldolgo- 
zásakor. 

Minden kockához tartozik egy ténytábla. A ténytáblák a mérté- 
kek és a kulcsok mellett szintén tartalmaznak két adminisztra- 
tív oszlopot a betöltő folyamat számára. 

Nézetek 

Ellenőrzőösszeg (checksum) view készül minden dimenziótáb- 
lához, az idődimenzió kivételével. Ezeket a Master Update 
DTS-csomagok használhatják, ha dinamikusan kell eldönteni- 
ük, hogy az előkészítő adatbázisban talált dimenziósor egy új 
sor (insert), vagy egy meglevő sor módosítása (update). 

A virtuális idődimenziókhoz szintén készül egy-egy view. 
Tárolt eljárás 

Az Upd Time Current tárolt eljárás az idő dimenziótáblák 
,current" oszlopait módosítja. Így a következő kockagenerá- 
lásnál az új dátum lesz , aktuális". 


Az RAO1 Staging előkészítő adatbázis 

Táblák 

A dimenzió- és ténytáblák mellett találunk hibatáblákat, és a 
betöltő folyamatot támogató paraméter- és kapcsolótáblákat. A 
hibatáblák az RAO1 adatraktárba történő betöltéskor hibásnak 
talált sorokat tartalmazzák. A paramétertáblák a DTS-csoma- 
gok globális változóinak értéket tárolják. 

A dimenziótáblák érdekessége az , InsertOrUpdate Ind" osz- 
lop, amely — ha a forrásadatokat biztosító folyamat kitölti — az 
I, U, D (insert, update, delete) értékeket tartalmazza. Így az 
RAO1 adatraktárba történő áttöltéskor a DTS-csomag könnyeb- 
ben, azaz gyorsabban el tudja dönteni, milyen változást jelent 
az adott sor. 

Tárolt eljárások 

Az adatraktár dimenzió- és ténytáblák aktualizálását végző 
DTS-csomagok munkáját támogató eljárások mellett különbö- 
ző naplózó és egyéb segédeljárásokat találunk. 


Fájlok és mappák 


A , Retail Analytics" munkafüzet a , data" mappában a követke- 
zőket hozza létre: 









ie geo ege d 










































Ele z ts 
a kezi a- 6 I A szareh E Fákés [F- 
Address [Ca c:iProgram FilesiMicrosoft SOL Server Accelerator for BlidatalRA01 
Folders HT x] (Name 
( BGadta 772222 
A (0 R401 EDebug 
A X cent Oors 
E) Mspa Olmport 
(XI) MSExXCEL work 
(B PROCLARITYCG ÁG analyticsgullderWB  RAO1.xis 
E Debug ) Ed config.ini 
B Oors (8]RA Delete RAO1.vbs 
A € Import RA Load RAO1.vbs 
C Format (E) RA Log 20030107. 120129. Ir 
H) Update ÉRA Log 20030107 120129 s 
H) Import ÉJ RA Log 20030107 120129 T 
OO) work (EJ RA Log 20030107. 120129 U 


A ,RAO1" mappa név az OLAP (és a Subject Matter) adatbázis 
nevével egyezik. Ha a munkafüzetben átírjuk az adatbázis ne- 
vét RAO2-re és lefuttatjuk a generálást, egy új, RAO2 nevű map- 
pa is létrejön. Miután az RAOx gyökerébe a generátor elmenti 
a munkafüzet aktuális verzióját is, egymástól függetlenül tárol- 
hatjuk az alkalmazás különböző verzióit. 


DTS-csomagok 


A DTS-csomagokat a DTS-mappában két csoportra osztva ta- 
láljuk. Az Import mappa azokat a csomagokat tartalmazza, 
amelyek a teszt adatokat az előkészítő adatbázisba töltik be. 
Az Update mappában találhatók azok a csomagok, amelyek az 
előkészítő adatbázis tartalma alapján az adatraktár tartalmát 
aktualizálják. 


DTS-import 

Az importálás vezérlőcsomagja a ,Master Import.dts". Ez pa- 
raméterezi és indítja a többi importcsomagot, amelyek a Sta- 
ging adatbázis dimenzió- és ténytábláit táplálják. Az egyes táb- 
lák betöltése , Bulk Insert" DTS-taskkal történik, ezeknek a for- 
mátumfájljait a Format mappa tartalmazza. Érdemes megje- 
gyezni, hogy ez a tesztadat-betöltő megoldás akár végleges is 
lehet - ha az inputadatokat a tesztadatok szerkezetének megfe- 
lelő szerkezetű szövegfájlokban kapjuk. Ha az inputadatok egy 
része nem szövegfájlokból, hanem például más adatbázisok- 
ból jön, elegendő a megfelelő importcsomagok átalakítása. 

A csomagok neve a következő szabályok szerint képződik: 
Import S Dim cDimID3 cHierID35 sLevID53.dts és 
Import S Fact cCubelD5 .dts, ahol 

az egyes cxxxID5-k rendre a dimenziót, a hierarchiát, a szin- 
tet, illetve az OLAP-kockát azonosítják. 


A DTS-csomagokat az SOL Server Enterprise Managerrel tud- 
juk megnyitni: jobb kattintás a Data Transformation Services 
mappán, majd Open Package. 


(EH Microsoft SOL Servers 

sg SOL Server Group 
ay KAROLYKO1 (Windows NT) 
E-É3 Databases 








öll Tasks 





Érdemes belenézni a ,Master Import.dts" csomagba. Első pil- 
lantásra nagyon nagynak és bonyolultnak tűnhet, valójában 
szépen rendezett, három logikai részből áll. A jobboldali blokk 
a paraméterek beolvasását végzi a config.ini fájlból, illetve a 
Staging adatbázis konfigurációs tábláiból. Ezután sok párhuza- 
mos szálon Execute Package taskok következnek, amelyek egy 
naplózó blokkban futnak össze. A használt DTS-technikák vé- 
gignézése tanulságos, felér egy kis DTS-tanfolyammal. A követ- 
kező ábra a csomag kezdetét mutatja: 



















A 
Log. Pkg Started 
5 Dim Prod Std .... 
Log Batch Compl.., A 
Generate Batch 
det 
S Dim Prod Std. ... 
A 
A 
Log. Bypass Set Gvs 
5. Dim Manuf. Stdi 
AN A j 
Pka.Speciic. Setup úgönsk Pickup, GVs 
5. Dim Hour. Std. , I 
A 
Common. Prop. Se... Server Setup 





b? 


5 Dim Entry. Std 


RT 


Config INI SetAs.. 








5 Dim Cust Std Zip 


4— 


Config. INI. RegR... 





























A legelső ActiveX script task a registryből kiolvassa a data map- 
pa elérési útvonalát, majd ezt, és a config.ini fájl címét globá- 
lis változókba tárolja. A script a következő: 
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Option Explicit 
Function Main() 
Dim wshShell 
Dim sConfigINIPath 
Dim sRegPath 
Set wshShell - CreateObject("WScript.Shell") 
sRegPath - wshShell.RegRead("HKEY LOCAL MACHINEN 
$ SOFTWARENMicrosoftAMSBISOWDatafiles") 
Set wshShell - Nothing 
sRegPath - sRegPath § "WV" 
sConfigINIPath - sRegPath £ "RAOlVconfig.ini" 


a 


DTSGlobalVariables ( "gsRegPath RESERVED" ) . Value 
4  sRegPath 

DTSGlobalVariables ( "gsRegRead. KESLEGNNLOL Ő .Value 
b sConfigINIPath 

Main - DTSTaskExecResult Success 

End Function 


A második (Config.ini SetAssignments5) task aktualizálja a har- 
madik (Server. Setup) taskban az ini fájl címét. Azt használja ki, 
hogy a DTSGIlobalvariables.Parent magára a DTS-csomagra 
mutat. A kód: 


Option Explicit 

Function Main() 

Dim sConfigINIPath 

sConfigINIPath - 

DTSGlobalVariables(" gsRegRead. RESERVED" ) .Value 

Dim OPKG 

Dim oAssignments 

Dim oAssignment 

Set oPKG - DTSGlobalVariables. Parent 

Set oAssignments - 

OPKG.Tasks(" Server. Setup. Task") .CustomTask. 

b Assignments 

For Each oAssignment In oAssignments 
oAssignment . SourceIniFileFileName . - 

sConfigINIPath 


Next 8 
Main - DTSTaskExecResult Success- 
End Function 


Érdekes a Pickup. GVs task. Végrehajt egy SELECT utasítást a 
Staging adatbázison, az eredményhalmazt, mint ADO sorkész- 
letet egy globális változón keresztül adja tovább a Set GVs 
task számára. Az inicializálás a Pkg Specific Setup taskkal zá- 
rul, ezután következnek az Execute Package feladatok. 


DTS-Update 


Az Update mappa több mestercsomagot is tartalmaz. Ezek kö- 
zül a legfontosabb a Master Update.dts. Ez a csomag — és az 
általa hívott dimenzió-, szint- és ténytábla-aktualizáló aláren- 
delt csomagok mozgatják át az előkészítő adatbázis tartalmát 
az elemző adatbázisba. A Master Update csomag fő részei: az 
inicializálás, a dimenziótábla-feldolgozó csomagok indítása, a 
ténytábla csomagok indítása, végül naplózás. 

A Dim. xxx.DTS-csomagok feladata a dimenziótáblák aktuali- 
zálása és az OLAP-dimenziók újraprocesszálása. Hasonlóan, a 
Fact xxx.DTS-csomagok a ténytáblákat bővítik, és elvégzik a 
megfelelő OLAP-kocka, vagy partíció feldolgozását. 


DTS- Globális változók 


A DTS-csomagok működését általában globális változók beál- 
lításával befolyásolhatjuk. Ezek a globális változók a Staging 
adatbázis Package GVs táblájában tárolódnak, módosításuk a 
Global Variable Configuration Utility"-vel történhet. 

Például a Dim xxx.DTS-csomagok működését jelentősen be- 
folyásolják a globális változók, különösen a giAlgorithm válto- 
zó. Értékei: 
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1 - AddOnly. Csak új dimenzióadatok vannak az elő- 
készítő táblában, tehát a dimenziótáblákat csak bőví- 
teni kell. 

2 - Flagged. Az előkészítő adatbázisban található di- 
menzióadatsorok címkézettek. A címke lehet: I, U, D 
(insert, update, delete). Az adatraktár-tábla aktualizálása a cím- 
kék alapján történhet. 

3 - Dynamic. Ez az alapértelmezett érték. Ekkor az új adatokat 
és az adatraktár meglevő adatait összehasonlítva derül ki, hogy 
insert, vagy update történt. A törléseket ekkor is jelezni kell az 
inputsoroknál. 


Hatékonyság szempontjából az első eset a legjobb, a harmadik 
a legrosszabb. Sok múlik azon, hogy a Staging adatbázis input- 
ját előállító folyamat mennyire intelligens. 


Az idődimenzió lokalizálása 


A ,Release Notes" említi, hogy az 1.1 verzióban az idődimen- 
zió feltöltését végző tárolt eljárások már nem titkosítottak. (A 
,Release Notes"-ot is illik elolvasni.) 

Az SOL Server BisoCatalog adatbázisában található ISym Lan- 
guage Add] tárolt eljárás elején található megjegyzés adja a 
megoldást: 


7. 
This stored procedure creates a new language in 
Decode Language, and adds to Language Decodes 
those items that must be localized in order to 
have an autogenerated time dimension in a new 
language. The items are created in English; they 
must be localized. Test carefully! 


See MSDN topic "Primary Language Identifiers" 
exec [Sym Language Add] 0x0c, "LanguageFrench!, 
"French", N"FranÜais! 
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Ennek megfelelően, magyar nyelv felvétele a következő SOL- 
utasítással történhet: 


exec [(Sym Language Add] 0x0e, "LanguageHungarian!, 
"Hungarian", N"Magyar" 


Ha ezután újra megnyitjuk az Analytics Builder munkafüzetet, 
az idődimenziónál megjelenik a magyar nyelv, de a generált 
idődimenzió-táblák még nyilván angol megnevezéseket tartal- 
maznak. Még nem kész a magyarítás, csupán az alapokat te- 
remtettük meg. 


A (Decode Languagel tábla csak a nyelvek listáját tartalmaz- 
za, ezzel nincs további teendő. 

A [Language Decodes] táblában az [Item Name) és az 
(ltem Label] oszlopok tartalmazzák a nyelvspecifikus informá- 
ciókat. A magyar nyelv azonosítójára szűrve 449 sort kapunk. 
Ez nem kevés, de elviselhető. A hónapok neveit és a hét nap- 
jainak neveit könnyen módosíthatjuk, ez csak 12 -- 7 sor mó- 
dosítását jelenti, de ha azt szeretnénk, hogy a dimenzió, a hi- 
erarchiák és szintjeik nevei is magyarok legyenek, már többet 
kell dolgoznunk. Bonyolítja a fordítást, hogy a táblázat jó né- 
hány képletet is tartalmaz: számított tagok és nevesített halma- 
zok definícióit. Ha azt akarjuk, hogy ezek a képletek a magyar- 
ra fordított idő dimenzióval jól működjenek, akkor nagyon 
gondosan kell dolgoznunk. Nem véletlenül írja a fent idézett 
megjegyzés: gondosan teszteld a lokalizálás eredményét! 


A [Language Decodes] tábla megfelelő sorainak lefordítása 
után is érhet bennünket meglepetés. A hónapok nevei egy-két 
helyen változatlanul angolul jelennek meg. Ennek oka, hogy 
az idődimenzió tábláit feltöltő tárolt eljárások közül kettő 
(Sym Time Fiscal Populate, Sym Time Std Populate) a 
datenameO SOL függvényt használja. A datename() eredménye 
az SOL Server session nyelvi beállításától függ. Ha magyar hó- 
napneveket szeretnénk mindenütt, vagy a két eljárás elejére 
kell beszúrni a ,set language hungarian" utasítást, vagy a ge- 
nerálást végző személy SOL Server login-jának alapértelme- 
zett nyelvét kell magyarra változtatni. 


(A szerző ezennel ünnepélyes, bár talán könnyelmű fogadal- 
mat tesz: Mire a cikk megjelenik, elkészítem a magyar idődi- 
menzió SOL szkriptjét!) 


További adatmodellek 
A Webről [4] további adatmodellek tölthetők le. 


Az ,ssabi financial services vertical kit.exe" egy lakossági 
pénzügyi szolgáltatásokat végző bank teljesítményjellemzőit 
és dimenzióit elemző alkalmazás sablonját és egy bemutató al- 
kalmazását tartalmazza. 


Az ,ssabi manufacturing vertical kit.exe" egy bicikligyártó cég 
példáján keresztül mutatja be, hogyan használhatók a Micro- 
soft üzleti intelligencia eszközei a gyártás hatékonyságának 
elemzésére. 


Összefoglalás 


Látható, az SSABI-vel sem csupán három kattintás egy üzleti 
intelligencia alkalmazás előállítása, de lényegesen egyszerűsí- 
ti egy ilyen alkalmazás előállítását. 

Az Excel munkafüzet szabályai rákényszerítik a fejlesztőt a kö- 
vetkezetes munkára. Minden kitöltött munkafüzet az újabb 
projektek sablonja lehet. Az alkalmazásgenerátor elvégzi a 
mechanikus kódolás jelentős részét. Az alkalmazássablonok és 
a dokumentáció sok hasznos ötletet, javaslatot tartalmaz. 


Kószó Károly 
rendszermérnök 
karolykemicrosoft.com 


A cikkben szereplő URL 


(11 http:/Avww.microsoft.com/sgl 
(2] http:/Awww.microsoft.com/sglfevaluation/bi 
(31 http:/Wwww.microsoít.comsolutions/bi/default.asp 


[4]. http:/Awww.microsoít.com/solutions/Bl/techinfo/datamodels.asp 
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Az adatok elosztásának igénye sok rendszerben megjelenik, így nem csoda, hogy az SOL Server 2000 
igen összetett és kifinomult infrastruktúrát biztosít az adatbázisok szerkezetének és tartalmának elosz- 
tására, replikálására. Cikkünkben fellebbentjük a fátylat a replikációról, így reméljük az írás végére 


érve új barátként üdvözlik azt. 


Mi is az a replikáció? 


Az SOL-replikáció alapvetően egy SOL Serverre épített alkal- 
mazás-arhitektúra, melynek segítségével adatokat lehet eljut- 
tatni más adatbázisokba, illetve össze lehet szinkronizálni bi- 
zonyos adatbázistáblák tartalmát. 

A replikáció önmagában egy bonyolult elméleti probléma, aki 
nem hiszi látogasson el az [1] címre a Microsoft Research hon- 
lapján, ahol kiderül, hogy a replikáció nem egyeszűen egy 
INSERT-SELECT párosról szól. 

Emiatt a replikáció elég sok gyakorlatot is igényel, különösen, 
ha valami nem megy a nagykönyv szerint. Ettől függetlenül 
nem kell tőle megijedni, tudatos tervezéssel, határozott kézben 
gond nélkül működik. Valódi, nagy adatbázisoknál viszont 
mindenképpen jól jön, ha valaki már pár órát eltöltött élőben 
replikáló adatbázisok előtt, és ami még fontosabb, ha tudja, 
pontosan hogyan működnek a replikációs ügynökök. 


Mire használható? 


Gyakori, hogy egy cégnek több telephelye van, ahonnan a dol- 
gozók munkájához szükség van valamilyen adatbázisra. Ha 
csak egy központi adatbázist hozunk létre, amelyet az összes 
telephely összes felhasználója egyszerre fog terhelni, könnyen 
teljesítményproblémák léphetnek fel. A másik kellemetlen ha- 
tás, hogy a valószínűleg nem túl gyors vonalak miatt az adat- 
elérés kellemetlenül lassú lesz. Ilyenkor például be lehet vetni 
a replikációt. 

Minden telephely kaphat egy lokális SOL Server-példányt (köz- 
vetlen közelségben a felhasználók által használt alkalmazás- 
hoz), a központi kiszolgáló erre küldi el a friss adatokat, illetve 
erről tölti vissza a módosításokat. Azaz a helyi SOL kiszolgálók 
gyorstárolóként (cache) működnek, a tárak közötti szinkronizá- 
ció meg legyen a replikáció gondja. 

Másik gyakori felhasználás a mozgó felhasználók támogatása. 
(Lásd ,Kicsi a bors, de erős!" című cikkünket a negyedik olda- 
lon.) Például egy utazó ügynök szeretne úgy dolgozni a laptop- 
ján, hogy azon minden számára szükséges adat rajta legyen, 
hogy a fő adatbázistól függetlenül tudjon terepen dolgozni. 
Amikor van hálózati kapcsolata (például modem vagy bemegy 
a cégéhez), fel tudja tölteni addig végzett munkája eredményét 
a fő kiszolgálóra. 

Emellett több kiszolgálóból összeállított webalkalmazásokban 
is segíthet a replikáció az adatok elosztásában, illetve OLAP- 
adatbázisok feltöltésére is használható. 


Replikáció-metaforák 

Mint minden szakterületnek, a replikáció tudományának is 
megvannak a maga szakszavai és metaforái, amelyek ismerete 
nélkül érthetetlen maszlag minden szakszöveg. 


A replikáció fogalomtárának kialakításához a hírlapszakmát 
választották alapul. A replikációs architektúra alapvető két 
résztvevője a Publisher (kiadóvállalat, publikáló) és a Subscri- 
ber (előfizető, feliratkozó). Általában a publikáló tárolja az 
adatok mesterváltozatát, a feliratkozó vagy feliratkozók erről 
kapnak másolatokat, replikákat. Kettejük között áll még egy 
szereplő, ő a Distributor (disztribútor, újságárus vagy nepper :). 
A disztribútor azért lett külön résztvevő, és azért nincs beleol- 
vasztva a publikációs szerepbe, mert így a feladatokat jobban 
szét lehet osztani több gép között (skálázás). Szép is lenne, ha 
az újságokat nem lehetne megvenni vagy előfizetni egy csomó 
disztribúciós ponton (posta, újságosbódé)! 

A hasonlat odáig megy, hogy a publikációk cikkekből (article) 
állnak, és önálló cikkekre éppúgy nem lehet előfizetni, mint 
ahogy az újságárus sem adja oda külön a sportrovatot az újsá- 
gokból. Tessék megvenni az egészet! 

A replikáció tervezésének lényeges része lesz a publikációk 
tartalmának értelmes összeválogatása. 





assssssssszszzszsszzzzsszsszeszssszsszsssssessssssss.s.. 




















Publikáció —— e Disztribútor —— o Feliratkozó. 


kessssssssssssssszssssssse. 





Replikációs feladatkörök 


Amikor - legegyszerűbb esetben - két gép replikál egymással, 
a kommunikációt mindkét oldal kezdeményezheti. Ha a diszt- 
ribútor kezdeményez, akkor Push replikációról, ha a feliratko- 
zó, akkor Pullról beszélünk. A valós életben ennek az felel 
meg, hogy ÉN kívánok újságot venni (tech.net magazin: Pull), 
vagy ŐK próbálják rámsózni (Fedél nélkül: Push). Ez nemcsak 
a tűzfalprogramozók szempontjából fontos, hanem az alkal- 
mazásfejlesztők munkájára és a kiszolgálók terhelésére is alap- 
vető befolyással van. 


Replikációtípusok 





Attól függően, hogy mennyire szoros kapcsolatra van szükség 
a feliratkozó(k) és a publikáló adatbázis között, valamint attól 
függően, hogy milyen irányban áramlanak adatok, háromféle 
replikációs algoritmust vethetünk be: Snapshot, Transactional 
(tranzakciós) és Merge. 

Snapshot replikáció során a forrásadatbázisból publikált ob- 
jektumokról egy létrehozó SOL script készül, a publikált táb- 
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lák tartalmát pedig bulkcopyval kimásolják fájlokba. 
A táblák tartalmáról tehát teljeskörű, minden adatot 
tartalmazó pillanatfelvétel készül. Ezt a feladatot a 
Snapshot agent (ügynök, közönséges SOL Server 
Job) végzi. Az eredmény egy könyvtárra való séma 
és bulk copy fájl. A Snapshot replikáció ezt tudja eljuttatni 
egy vagy több feliratkozóra. Nyilvánvaló, hogy ez a repliká- 
ció nem tud folyamatosan működni, csak periodikus, szaka- 
szos működéssel tudja szinkronizálni a feliratkozókat, és min- 
den alkalommal mindent újraépít (alapértelmezésben), így 
nagytömegű adatok ismétlődő átvitelére nem ez a megfelelő 
módszer. 

A Snapshot replikáció legnagyobb jelentőségét az adja, hogy 
a másik két módszer is ezt használja a feliratkozók kiindulási 
adatbázisának kezdeti feltöltésére, szinkronizálására. 
Tranzakciós replikációban egy LogReader nevű agent folya- 
matosan olvassa a tranzakciós logot, és a publikált táblák tar- 
talmára vonatkozó változtatások, tranzakciók adatait elküldi a 
disztribútornak. A disztribútor aztán a Distribution Agent(ök) 
segítségével elpostázza a tranzakciókat a feliratkozóknak. Ez 
azt jelenti, hogy a publikáló és a feliratkozó adatbázis között 
akár pár másodperc késleltetéssel is átvihetők a változásokról 
szóló infók, azaz - folyamatosan futó szinkronizáció során - 
elég szoros csatolás hozható létre a két oldal között. 

Viszont abban az esetben, ha akár ugyanazt a sort egymás 
után egymilliószor módosítják a publikált adatbázisban, mind 
az egymillió tranzakció tényét egyesével átjátsszuk a másik ol- 
dalra, ami nyilvánvalóan nem túl hatékony nagyon sűrűn mó- 
dosított adatbázisok esetén. Ekkor a másik két módszer haté- 
konyabb tud lenni. 

Az utolsó és egyben legbonyolultabb replikációs típus a Mer- 
ge replikáció. Ebben feliratkozó oldalon is lehet módosítani az 
adatokat, amely módosítások a következő szinkronizáció so- 
rán visszaáramlanak a publikáló adatbázisba, majd onnan a 
többi feliratkozóra. Ebben a rendszerben a triggerek figyelik és 
(replikációs rendszertáblákba) rögzítik változtatásokat, ame- 
lyeket a Merge Agent továbbít a publikált adatbázisba. Egy re- 
kord többszöri módosítása egy darab tételként kerül rögzítés- 
re és megy át a szinkronizációs kommunikáció során. 

A Merge replikációt tipikusan lazán csatolt, gyakran lecsatolt 
alkalmazásokban használják (mint a korábban emlegetett 
ügynökadatbázis), de persze más rendszerekben is jól hasz- 
nálható. A többivel szemben nagy előnye, hogy a publikált 
táblákat a feliratkozó felhasználótól függően lehet szűrni, így 
minden felhasználó csak a rá vonatkozó adatokat kapja meg. 
A másik két módszer ezt nem ismeri. 


"zzz 


Csapjunk bele! 


A replikációk eléggé bonyolultak, így ahelyett, hogy oldalakon 
keresztül az elmélettel untatnám a kedves olvasókat végig- 
nyomkodjuk a Snapshot replikáció varázslóját, és menet köz- 
ben vesszük át a szükséges elméleti tudományt. 

Példáinkban egy számítógépen fog futni a publikáló és a feli- 
ratkozó adatbázis is. A CSHARPNSOL1 nevű példány lesz a 
Publisher, a CSHARP pedig a feliratkozó. A példák a North- 
wind adatbázisra épülnek. 
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A további példákban szereplő két SOL Server és a 
Northwind példaadatbázis. Jól látható az üres Replica- 
tion-ág 
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A publikálandó adatbázison jobb gombot nyomva a New 
Publication menüből kiindulva indíthatjuk el a publikáló va- 
rázslót. (A replikáció az a technológia, amelyet varázslók nél- 
kül csak sámánok és életművészek képesek elindítani.) 


The Next Generation 


A Next generáció gyermekei munkaidejük legalább felében a 
Next gombot nyomogatják. A most következő x oldalon ke- 
resztül a varázsló lépései következnek. Nem számoltam, de 
legalább húsz lépésből áll a legegyszerűbb varázslat is. Ha ez 
sikerül, jobbak vagyunk, mint Harry Potter! 


€reate Publication Wizard § 3 












§ Welcome to the Create Publication 
-- Wizard 


This wizard helps you pubfsh your data so that ít can be shared 
with Subseribers. With this wizard you wilk 


6  Publishthe data in database "Northwind. 


9 Filterthe data in the publication. 
5 Setthe publication properties. 
After the publicalion is created, the data can be shared with 


servers running SOL Server and heterogenecus data sources by 
creating subscriptions 


Ed Elindul a publikációs varázsló. Bekapcsoljuk az 
advanced opciókat is, így minden fontos részletre kitér- 
hetünk. 


Next. 


Create Publication Wizard ú 


Select Distributor ú 





Choose a Distributor for this server because it ís a new Publisher. 5! 
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C Use the following server (the selected server must already be configured as a Distibutor): 


CSHARP Adg Beret, I 
HOODBOO3 

HOOW3072 

PLATAN 

IVMLONDONYUDOI 








ese [2 ten 
E A disztribútor kiszolgáló kiválasztása 


Meg kell adnunk, hogy melyik szerver lesz a disztribútor. Em- 
lékezzünk vissza, ő a nepper, akin csak átfutnak az adatok, de 
nem tőle származnak, és nem nála kötnek ki! Erre a szerepkör- 
re egy közönséges SOL Serverre van szükség, amelyet azonban 
fel kell készíteni a feladatra. Látható a varázsló képéből, hogy 
itt kiválaszthatnánk egy másik gépen már létrehozott disztribú- 
tort, illetve létrehozhatunk egyet a sajátunkon. Most hozzunk 
létre egy újat a sajátunkon. Next. 


SOL Server Enterprise Manager 


SAL BE ázrk s ESHAHESAL een keztek KÉT, 8 
HaLEeS Ér eset oten torvera et/etlT Vo ZETETSSEOS Ez kSzsEletl -§ 
"account for the Service startup sccount. § 








E Az SOL Server jelenleg Local System alatt fut. Ez kap- 
csolódási problémákhoz vezethet! 


A figyelmeztetés jogos. Replikáció során egyes ügynököknek 
hálózati megosztásokat kell elérni. Mivel az ügynökök SOL 
Server Agent Jobok, a megosztásokat is az SOL Server Agentöt 
futtató account nevében érik el. Mivel az nálam jelenleg a 
System account, könnyen lehet, hogy nem érik el a megosztá- 
sokat. Ezért a következő ablakban rögtön át is állíthatjuk a Ser- 





vice accountot valami lokális vagy (még jobb!) Do- 
main felhasználóra. Cancel, most egy gépen dolgo- 
zunk csak, nem lesz nagy gond. 





Create Publication Wizard 


Select whether to automatically start the SOL Server Agent service when the computer ( —] 


Configure SOL Server Agent u 
sek 8 





the repácation agents that sznchronize subscriptions run unattended, it is 
TEEGESSTTTÁS LU SETS ÁSNÉ le Atesl S ÜST ÉSÉT 


Doyou want to configure the SOL Server Agent service on CSHARPASALT" to start 
öutomaticaly when the computer is started? 


6 [ez ethe SÜL Server service to start aut 


C Ne. wil start the SOL Server Agent service manualy 





Dem [s] 





B A replikációs ügynököket az SOL Agent futtatja — már 
ha fut. Állítsuk be automatikus indításúra! 


Ahhoz, hogy a replikációs ügynökök folyamatosan futhassa- 
nak, az SOL Server Agentnek is folyamatosan kell futni. Hadd 
tegye a dolgát a varázsló! Next. 


Create Publication Wizard 









Specily the root location where snapshots of all publications from this Publisher wil be 


Specify Snapshot Folder gi 
stored. 





To support Distrbution and Merge . ÜZE LEÉLT ASÁA EST TE ESEK 
subscíiptions, you sk Tt Fal tözg atöpattEMÉSKÉS ESKRÜ network path. 





Snapahot folder 




















E Hol legyen a Snapshot mappa? Ne a C$ megosztáson, 
annyi szent! 


Bármilyen típusú publikációt is fogunk létrehozni, a Snapshot- 
ra szükség lesz a feliratkozók kiindulási állapotba hozásához. 
A Snapshot mappa mindenképpen egy hálózati megosztáson 
kell legyen, hogy a Merge ügynök (Merge replikáció) vagy 
Disztribúciós ügynökök (Snapshot és Tranzakciós replikáció) le 
tudják tölteni a szükséges fájlokat. Push replikáció esetén a 
Merge és Disztribúciós ügynök (általában) a disztribútoron fut- 
nak, míg Pull esetén a feliratkozókon. Ez azért fontos, mert ez 
meghatározza, hogy az ügynökök milyen Windows 2000 fel- 
használó nevében futnak, hisz ezeknek kell jogosultságot adni 
a fájlmegosztáshoz. Mobil felhasználás esetén Pull feliratkozást 
szoktunk használni, hisz ilyenkor a disztribútornak fogalma 
sincs, mikor lesz hálózatközelben például a laptopon futó feli- 
ratkozó, így Push esetén feleslegesen erőlködne a szinkronizá- 
cióval. Ha Pull replikációt választunk, a Merge vagy Disztribú- 
ciós ügynök a feliratkozó gép SOL Server Agentje nevében fut, 
ha a szinkronizáció ütemezetten vagy az Enterprise Manager 
segítségével indítjuk el. Mivel általában a laptopos SOL Server 
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és az Agent is Localsystem vagy valami lokális admi- 
nisztrátor nevében fut, lehet, hogy nem tudja elérni a 
megosztást. Ilyenkor sokszor nem marad más, mint 
Everyone-nak Read jogot adni a megosztásra. 

Abban az esetben, ha a replikációt parancssorból 
vagy a Windows Synchronization Manager segítségével indít- 
juk el, az ügynökök az interaktívan belépett felhasználó nevé- 
ben kapcsolódnak hozzá a disztribúciós adatbázishoz és/vagy 
a publikálóhoz. Ez remekül kihasználható személyre szabott 
adatok replikációjához. (A Merge replikáció dinamikus filterek 
használatára is képes.) 

Ha valódi, helyhez kötött kiszolgálók között hozunk létre rep- 
likációt, áltálban az összes SOL Server Agent ugyanazon tarto- 
mányi felhasználó nevében fut, ilyenkor annak kell jogot adni 
a megosztásra. 

De visszatérve a varázslóhoz, az alapértelmezésben felajánlott 
adminisztrációs megosztás (C$) helyett mindenképpen készít- 
sünk egy saját könyvtárat és megosztást, ahol a Snapshotokat 
fogjuk tárolni. Itt elég jelentős méretű adatok is összejöhetnek, 
ezért érdemes átgondolni melyik meghajtóra vagy Raid tömb- 
re helyezzük el a fájlokat. Akár külön fájlszervert is használha- 
tunk erre a célra, nem kötelező a disztribútor szerverre rakni a 
snapshot fájlokat. 

Példánkhoz létrehoztam egy Snaps nevű könyvtárat a C:Y el- 
érési úton, amelyet megosztottam SOLReplISnaps néven, és 
Everyone-nak Change jogot adtam rá. Ez így, ebben a formá- 
ban persze egyáltalán nem biztonságos, de kénytelen vagyok 
ezt tenni, mert az SOL Server Agent a disztribútorszerveren 
(CSHARPNSOL1) System account alatt fut, így a Snapshot 
Agent csak így tud írni a könyvtárba. 

A varázslóban írjuk át az alapértelmezett Snapshot foldert a sa- 
játunkra. 


Create Publication Wizard BEKE, íz 


Specify Snapshot Folder új 





Specily the root location where snapshots of all pubfcations Írom this Publsher wil be 
stored. 





To suppott Distribution and Merge Agents that run at Subscribers, such as for pull 
 subscnptions, you must refer to the snapshot folder using a network path. 


Snapshat folder: 





[med] ten ] 





Id Saját disztribúciós mappa megadása 


Ezzel végeztünk is a disztribútor konfigurálásával (egyelőre). A 
következő lépések már a publikálásról szólnak. Első, alapvető 
kérdés: melyik adatbázist akarjuk publikálni? 





E A publikálandó 
adatbázis kijelölése 











sp zi 






B A replikáció típusa 


Ez SZEEZEE az első példában 
EST z ete 
EE SET snapshot legyen 
VESZTETT ár 
ÉG ELLE ÉEEETT KE NEZET 
DEKREANKESES SSE ESET SEBI Next. 





E Mit tegyünk a felirat- 
kozóknál előálló módosí- 
tásokkal? 


€ ggg márt cry mt ermamt ba mot iát aycmita aátmdáte 


1 öman non ey Bamm 3521 öieem dstbáne TO tag drsám atm Wtaczaam 
beee te snáteteri 


sa jeges] essel tzetől Next. 


No, ez egy érdekes lépés, érdekes kérdés! Alapvetően a Snap- 
shot és a Tranzakciós replikáció egyirányú, azaz a Publisheren 
történt változások, melyek több-kevesebb késleltetéssel eljut- 
nak a feliratkozókhoz, az ott történt változtatásokat a követke- 
ző szinkronizáció során nagy valószínűséggel felülírják. 
Viszont mindkettőt rá lehet bírni arra, hogy a feliratkozón vég- 
rehajtott INSERT-UPDATE-DELETE-ek illetve komplett tranzak- 
ciók azonnal hajtódjanak végre a publikáló adatbázisban IS. 
Ezek az UPDATE-elhető (módosítható) replikációk. 

Nyilván a módosítás egy elosztott tranzakcióban valósul meg, 
amelyhez a feliratkozónak el kell tudni érni a publikálót. Emitt 
a módosítható Snapshot vagy tranzakciós replikációnak elég 
erős követelményei vannak a hálózati kapcsolattal szemben. 
Mire jó ez? Olyankor használható ki, ha exkluzív erőforrásokat 
kell lefoglalni elosztott módon. Erre a Merge replikáció nem 
megfelelő, mert ott a késleltetések miatt lehet, hogy ugyanazt 
az erőforrást többen is lefoglalják. Persze ez konfliktust szül a 
szinkronizáció során, amelyet a Merge replikáció automatiku- 
san lekezel, de kizárólagos erőforrásoknál ez sovány vigasz a 
hopponmaradtaknak. 

Gondoljunk el például egy repülőjegy-eladó rendszert. A pub- 
likáló gépen vannak felsorolva a szabad helyek. Minden egyes 
területi utazási iroda óránként megkapja (például Snapshot 
replikációval) a foglalások tábla legfrissebb tartalmát. Betér egy 
utas Alsómocsoládra, és kér egy jegyet az Air France Seychelles- 
re tartó repülőgépére. A replikált táblából látszik, hogy a 
12-13-as ablak melletti helyek szabadok, ezért azt le akarja 
foglalni. Ne felejtsük el, hogy a szabad helyek listája már lehet, 
hogy 59 perccel ezelőtti állapotot mutat. A kisasszony megkí- 
sérli lefoglalni a két helyet, azaz egy UPDATE-et hajt végre a 
feliratozott gép foglalások tábláján. Ez — mivel a replikáció mó- 
dosíthatóra van beállítva — automatikusan elindít egy elosztott 
tranzakciót a publikáló adatbázissal, amin persze a valódi ál- 
lapot látható. Ha a két hely tényleg szabad, a módosítás mind- 
két oldalon sikeres lesz, ellenkező esetben minkét helyen le- 
pattan (ROLLBACK-elődik). 

Azaz a feliratkozó táblája cache-ként működik, így — több-ke- 
vesebb pontossággal — a lekérdéseket helyben meg lehet tenni, 
de a módosítások mindig a publikálóval szinkronban hajtód- 
nak végre. 

Ennek a módszernek egy pikánsabb változata, amikor a felirat- 
kozón történt módosítás ténylegesen lezajlik, és a módosítás 
ténye bekerül egy várakozási sorba, egy Oueue-ba. Ez a Oueue 
lehet egy SOL Server tábla a feliratkozón vagy Microsoft 
Message Oueue is. Amikor a publikáló adatbázis elérhető, a 
OXueue Reader Agent kiolvassa a feliratkozón összegyűlt tran- 
zakciókat, és azokat megpróbálja rájátszani a publisherre. 


HAGáa s 4Wid 


A késleltetés miatt nyilván konfliktusok léphetnek fel, ami 
ugyan feloldható, de alapvetően ez a módszer nem alkalmas 
exkluzív erőforrások foglalására. 

Immediate updating esetén a feliratkozóra replikált táblák trig- 
gerekkel lesznek felszerelve, ezek intézik az elosztott tranzak- 
ciókat. 

Példánkban kihagyjuk az azonnali módosítás lehetőségét, az- 
az a feliratkozó csak olvasható lesz. 

Abban az esetben (ez a gyakori), ha egyes táblákat jó lenne mó- 
dosítani a feliratkozónál, másokat viszont nem, nyugodtan lehet 
keverni a replikációs típusokat. Például 23 viszonylag állandó 
tábla (kódtáblák, felsorolások, városok, megyék listája, stb.) me- 
het tranzakcióssal, míg a felhasználók munkatáblái merge-dzsel. 





B Átalakítsuk-e az ada- 
tokat a replikáció során? 
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Oo mutat karsám ha ütt hata hahota a Fssaztáan? 
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Lehetőségünk van arra, hogy az adatok nem az eredeti formá- 
jukban érkezzenek meg a feliratkozókhoz, hanem átalakítva. 
Ehhez ki lehet használni a DTS lehetőségeit, de ez egy ,advan- 
ced" lehetőség, most nem élünk vele. Fontos viszont, hogy ez- 
zel csak akkor élhetünk, ha a publikáció létrehozásakor meg- 
adjuk, később már nem lehet módosítani ezt a tulajdonságot, 
hanem újra létre kell hozni a publikációt! 


7 E Milyen adatbáziskeze- 
lők kapják meg a replikált 
adatokat? 





ieeényyzáseutyls 
ITOgvrore sar 





e maanart ta vanáora Be dőlő hatan da datszal ia adot 
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JESESSTESSTESE Next. 


Nyilván a legteljesebb szolgáltatáshalmazt homogén SOL Ser- 
ver 2000 adatbázisokkal érhetjük el, de érdekes dolog, hogy 
gyakorlatilag bármilyen adatbázisra replikálhatunk, amihez 
van OLEDB vagy ODBC meghajtó - legalábbis Push módon. 
Persze ilyenkor az adattípusok és egyéb adatbázisjellemzők 
összehangolása okozhat némi fejtörést. Next. 


Create Publication Wizard 


Specily Articler ú 





Publish tables and other database objects as articles. You can filter Ihe published data 
later in the wizard. 





Choose the database objects to publish as articles. 










Territories 
CustOrderkHist 
CustÖrdersDetal 
CustÖrdersÜrders ül 
Employee Sales by County 

Sales by Year 


SalesgyCategory 
Ten Most Expensive Products 























Milyen adatokat szeretnénk publikálni? 


Az SOL Server 2000 táblákat, nézeteket, tárolt eljárá- 
sokat és függvényeket képes replikálni. Ezeket egysé- 
gesen cikkeknek (article) hívjuk a replikációs termi- 
nológiában. 

Melyikből mi megy át a feliratkozókhoz? A tábláknak a szerke- 
Zete és az adatai is ,átmennek". Ha rákattintunk egy tábla mö- 
götti ...-re, definiálhatjuk a sémagenerálás részleteit. 





Table article Properties - Region 








HOSNETNI 
G A cikk (article) adatai 


A Destination table name segítségével új nevet adhatunk a cél- 
táblának. A Destination table ownernél pedig megadható egy 
új tulajdonos. Általában szeretjük, ha az összes objektumnak a 
dbo a tulajdonosa (így egyszerűbb a jogok kiosztása). Ha itt 
nem adunk meg semmit, a létrehozott tábla annak a tulajdoná- 
ban lesz, aki azt létrehozza. Ki lesz az? Vagy a Disztribúciós 
ügynök, vagy a Merge ügynök. Ha ezeket az ügynököket futta- 
tó account nem db. owner a feliratkozó adatbázisban, az acco- 
unt lesz a tulajdonos, és nem a dbo. Például kézzel indított 
Pull Merge replikáció esetén az interaktívan belépett felhasz- 
náló nevében fut a Merge ügynök, így annak a felhasználónak 
kell legyen joga adatbázis objektumokat létrehozni. Ha ehhez 
nem a db owner hanem például a db ddladmin szerepkörön 
keresztül kap jogot, a létrehozott táblának a felhasználó lesz a 
tulajdonosa és nem a dbo. Ezt elkerülendő érdemes explicit 
megadni a dbo-t mint ownert! 

A tábla article-ök másik fülén további jellemzőket állíthatunk be: 





7 DROP the műkny te ad eosole k 


C Drjetn data in the ééírg tatás tal málctas ba row Mor CC Özjele data inte eszáro tata that matchhet the rom Eder 
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E A Snapshot replikáció alapértelmezésben, és némi ixel- 
getés után 
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A Snapshot replikáció alapértelmezésben minden 
egyes alkalommal ki akarja törölni a feliratkozón ta- 
lálható céltáblát, hogy újra létrehozza azt (DROP ...). 
Ez a csak olvasható módon használt táblák esetén 
(tranzakciós és snapshot replikáció) általában nem 
gond, hadd takarítson. Azonban abban az esetben, ha a céltáb- 
lákat idegen kulcsok (foreign key, referencial integrity) kötik 
össze, a törlés nem biztos, hogy sikerülni fog, mert az ügynö- 
kök nem törődnek vele, hogy a hierarchia vége felől visszafelé 
haladva töröljék a táblákat. Ha ebbe belefutunk, két dolgot te- 
hetünk. A legegyszerűbb, hogy nem visszük át az idegen kul- 
csokat, erre szolgál az Include declared referential identity 
checkbox. Merge replikációnál ez nem túl , buli", mert ott a fe- 
liratkozónál is módosítanak, ahhoz meg nagyon kellenének az 
idegen kulcsok. Ebben az esetben a snapshot letöltés előtt és 
után meg lehet adni saját scripteket, amelyeket lefuttat a repli- 
kációs infrastruktúra, így abban kézzel törölhetjük az idegen 
kulcsokat a snapshot átvitele előtt. 

Látható, hogy egy táblához tartozó összes kacatot képes át- 
vinni a replikáció, csak be kell őket ikszelni. A Convert user- 
defined to base data types kapcsoló azt jelenti, hogy a forrás- 
táblában található oszlopdefiníciókat, amelyeket általunk defi- 
niált adattípussal hoztunk létre, a feliratkozók már visszaalakí- 
tott módon, valamely SOL Server adattípusra visszavezetve 
kapják meg. Ha ez nekünk nem tetszik, érdemes kiikszelni ezt 
a checkboxot, viszont ebben az esetben nekünk kell gondos- 
kodni arról, hogy a snapshot letöltés előtt az adattípusok ké- 
szen legyenek a cél (feliratkozó) adatbázisban, máskülönben 
elhasal a szállító ügynök. Erre is tökéletes a korábban emlege- 
tett pre-snapshot szkript. 

Ha valamit nem használunk ki, (például az Extended property- 
ket), kár leszkripteltetni és átvitetni, mert csak lassabb lesz tőle 
a snapshotgenerálás és átvitel. 

Mivel rengeteg tábla esetén elég unalmas a checkboxokat vé- 
gigkattogni, ezért a hárommal ezelőtti lépésben látható egy Ar- 
ticle Defaults nevű gomb. Itt articletípusonként (tábla, tárolt el- 
járás, stb.) megadhatjuk az alapértelmezett beállításokat, így 
minden article ennek megfelelően lesz beállítva. Ezután a ki- 
vételeket már egyesével átkonfigurálhatjuk. 


Default Article Type 





E Az alapértelmezések átállítása sok kattintástól kímél 
meg minket! 


Tárolt eljárások, nézetek és függvények esetén az objektumok 
törzse (szkriptje) megy át a feliratkozókhoz, itt is beállítható, 
hogy a már létező, azonos nevű objektumokat először töröljék. 
Next. 


BH Milesza 
publikáció neve és 
leírása? 





Mint az már gondolom kiderült, egy adatbázisban akárhány 
publikációt létrehozhatunk, és általában ugyanazt a táblát, 
függvényt, satöbbit akárhányszor publikálhatjuk, ha különbö- 
ző jellegű feliratkozóknak más és más igényei vannak. 

Next. 


EB Nem zárt 
csoportok publi- 
kálása figyelmez- 
tetést okoz! 





A zárt csoport SOL-objektumok (táblák, nézetek, eljárások) 
olyan halmaza, amely tartalmazza az összes olyan társ-objek- 
tumot, amire a többiek hivatkoznak. Azt mondja a varázsló, 
hogy publikált nézetünk hivatkozik olyan táblára, ami nincs 
benne a publikációban. Hasonló baja van a tárolt eljárásunk- 
kal is. Igaza van, de szerencsére ettől még nem áll le a varázs- 
ló, ez csak figyelmeztetés. Viszont ezek az objektumok tényleg 
csak akkor fognak működni a feliratkozón, ha az alattuk levő 
táblákat valami más módon lejuttatjuk a feliratkozókra. Példá- 
ul kézzel, scriptelve vagy más publikáción és feliratkozáson 
keresztül. 


E A publikáció 
elkészítése, vagy 
tuningolása követ- 
kezzen? 





Ezen a ponton be is fejezhetnénk a varázslást, de kár lenne, 
mert az igazán izgalmas lehetőségek csak most jönnek. 
Next. 


B A publikált 
adatok szűrése so- 
rok és oszlopok 
szerint 


A publikálandó adatokat (tábla article-öket) függőlegesen (osz- 
lopok) és vízszintesen (sorok) is lehet szűrni. Válasszuk ki 
mindkettőt. 

Next. 



























Create Publication Wizard 





Filter Table Columns 14 
Exciude unwanted table columns írom the articles ín your pubőcation. -ú- 





Select a table, and then clear the check boxes in the column Fist to exciude unwanted columns, 


"Columns in selected table: 






Region 


Tenitories Teritories 





A függőleges szűrés oszlopok kihagyását jelenti 


Most függőlegesen szűrünk, azaz elhagyhatunk oszlopokat a 
táblákból. Csak megfontoltan! Next. 


Create Publication Wizard 


Filter Table Rows 
Exciude unwanted tows Írom the articles in your pubfcation. 





ck the buld (.] button to fiter the rows of an article 
lovme be ját jen mi [JJ 
ERHET 
c Allrows published ; 
c Allrows published : 


IZE 
Region 
Tenitories 








Region 
Termitories 











A vízszintes szűrés nem más, mint sorok szűrése 


A ...-re kattintva mehet a sorszűrők beállítása táblánként. 
Például: 


EYES EKET a 
Mé 

f[ddoAteustomers] 

feustomers 


Complete the WHERE clause in the following SELECT statement. The 
Ess should specify the rows from (dboj.(Customers) to be included in this 
artiol 





Iable to filter 


Article name: 





Note: IÉ you refer to the table to filter in the WHERE clause, you must use 
the keyword KSTABLE5? in place of the table name. 


SELECT épublished columns? FROM ccTABLE22 WHERE County - a 
UK" 







s 
p 
For example, to include rovws only for Ohio businesses ín a table named 
contact, type: cc TÁBLE33.state z OH" 





Tr emet [2 Heb ] 


E A sorszűrés egy WHERE-feltétel megadását jelenti 





Szűrési feltételként lehet használni FOR REPLICATI- 
ON záradékkal létrehozott tárolt eljárást is, de ebbe 
most nem megyünk bele. 

A szűrési feltételek kiértékelésre azaz végrehajtásra 
kerülnek a Snapshot létrehozásakor, amely megfele- 

lő indexek támogatása nélkül igencsak lassú lehet. Next. 


ke] 

z 
"en 

— 





E Engedélyezzünk-e 
névtelen előfizetőket? 





A publikáció létrehozása után egyesével bekonfigurálhatjuk, 
hogy mely SOL Serverek iratkozhatnak fel a publikációra. Ez 
azt jelenti, hogy 100 feliratkozó esetén mind a százat explicit 
be kell rakni a potenciális feliratkozók közé, és a feliratkozás 
során a kapcsolatfelvétel tényét közölni kell a publikáló adat- 
bázissal. Ez zárt vállalati rendszerben így jó, hisz például egy 
Windows 2000 tartományba se ülhet bele bárki a kóbor mun- 
kaállomásával. 


Viszont Internetes, ismeretlen feliratkozók esetén jól jöhet az a 
lehetőség, hogy a Publisher konfigurálása nélkül fel lehet irat- 
kozni a publikációra. Persze ekkor a biztonsági követelménye- 
ket alaposan át kell gondolni. Tranzakciós replikáció esetén a 
tranzakciók tárolási idejét és helyszükségletét is alaposan fel- 
borítja az Anonymusokra való felkészülés. Most nem élünk ez- 
zel a lehetőséggel. Next. 







E A Snapshot Agent idő- 
ezzen zítése 


vese 
SZAT 


ezet némán 


TESZ ES E tő 


Amikor egy feliratkozó szeretne lekérni egy friss snapshotot a 
publisherről, annak rendelkezésre kell állnia. Ha például órán- 
ként szinkronizálnak a snapshot feliratkozók, óránként érde- 
mes újrageneráltatni a snapshot folder tartalmát, hogy a felkap- 
csolódók tényleg a friss képet vigyék el. A Change gombra kat- 
tintva a szokásos ablakban beállíthatjuk a Snapshot Agent fut- 
tatási ütemezését. 


Next. 





jeez azaz e 


am JEE [een [25] 








E És ez már a vég(e)! 


A Finish megnyomása után nagy sürgés-forgás kerekedik a gé- 
pen, és létrejön a disztribútor valamint a publikáció. 

Az utolsó ablak arról tájékoztat, hogy a replikáció állapotát a 
Replication Monitoron keresztül figyelhetjük meg. 


7] 
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" Replikáció az S0L szerverben / 501 


Tész 


A 














E A kész publikáció látképe az Enterprise Managerben 


Itt az ideje, hogy feliratkoztassunk valakit a publikációnkra! Ké- 
szítsünk egy Push (rátukmálós) feliratkozót. A Northwind nevű 
publikációnkon (a képen ez az aktív) jobb gomb, majd a Push- 
New Subscriptionre kattintva indul el feliratkoztató a varázsló. 


E Push típusú feli- 


ratkozás készítése, 
Herzl nákjegb, THURALOLT ös a mere Advanced lehetősé- 
ESSÉSett gekkel 
P goz zncsáosena na vizs] 

Next. 


E Ezen a lapon ki- 
választhatjuk a fel- 
iratkozó szervert. 


Next. 


B Az adatokat fo- 
gadó adatbázis neve 


Next. 


A céladatbázis nevének nem feltétlenül kell megegyeznie a 
publikáló adatbáziséval, de a replikáció első elindításakor már 
létezni kell. 


B Hol fusson 
a disztribúciós 
ügynök? 


WöT Gt dd Vita is dt. 


t 











A disztribúciós ügynök az a program, amely átvödrözi az ada- 
tokat a publikációs vagy a disztribúciós adatbázisból a felirat- 
kozó adatbázisba. Mivel ez egy egyszerű program, futhat mind 
a disztribútor szerveren, mint a feliratkozón. Alapértelmezés- 
ben Push replikációnál a disztribútoron fut, Pullnál a feliratko- 
zón, de ebben a lépésben ez módosítható. A módosítás oka tel- 
jesítményelosztás lehet. Next. 


Most be kell állítanunk mikor fusson a disztribúciós ügynök. 
Állítsuk be, hogy óránként menjen, de úgy, hogy az előző 
Snapshot, ami éjféltől számítva egyóránként generálódik, már 
készen legyen. Ezért fél egytől óránként fog futni. A Snapshot 
ügynök működése nagyon le tudja terhelni a publikáló szer- 
vert, így érdemes a működését akkorra időzíteni, amikor nem 
fut más. 


[3 Induljon 
a replikáció! 


Next. 


Ha kérjük, a varázsló utolsó lépéseként azonnal elindítja a 
Snapshot ügynököt, hogy legyen egy friss snapshotunk a most 
feliratkozott adatbázis inicializálásához. 

Next, Finish és vége. 


E Ügynökvilág Ma- 
gyarországon 


Smith ügynök alatt (jobb oldalt) megjelent egy kolléga, egy 
disztribúciós ügynök. Ő az, aki eljuttatja a párja által legene- 
rált snapshotot a feliratkozókra. A szinkronizációhoz már csak 
el kell indítani a disztribútor ügynököt: jobb gomb, Start 
Synchronizing. Első kísérletünk csúfos kudarcba fullad: 


E A replication 
monitor hibát jelez 


A piros Replication Monitor a replikációt adminisztráló embe- 
rek rémálma, előbb-utóbb az ember nyugtalanul alszik miatta. 
De azért az ügynökre kettőt kattintva fény derül a problémára: 


ENE Ea. B tc 





3 
Pubfsher JCSHARPASOL1 Agent fEGHARFSALT Nodhwnd CSHAF 
Pubfcationc  Subsciiption JEHARENattwindztepi 


Last.sommand: FE 


Eror message:  [Unable to repíicate a view or function because the referenced objects or columns are 2 
not present on the Subscriber. 





Erordetals:  finvaid obiset name Calegoses. 
(Source: CSHARP (Data source): Enor number: 208) 


Invalid object name Products. 
(Source: CSHARP (Data source): Errot number: 208) 


Unable to replicate a view or function because the referenced objects or columns are 
not present on the Subsciiber, s] 





Agent History ! Mew Agent I ose 


Ed Kár volt fittyet hányni a korábbi figyelmeztetésre (hi- 
ányzó objektumok)! 





Sajnos a varázslónak lett igaza. Publikált nézetünk és tárolt el- 
járásunk olyan táblákra hivatkozik, amely nem szerepel a cé- 
ladatbázisban. Tegyük hát bele! Vegyük elő a publikáció tulaj- 
donság lapját, váltsunk át az articles fülre, és adjuk hozzá a hi- 
ányzó táblákat a publikációhoz. 


3 
Updatable ] Si 1 Snapshot Location Pubécation Access List] Status] 
General Áricles ] FiterColumne ] FiterRows ]/ Subsciiptions  ]/ Subsciiptión Options. [/ 







Spor he otieciuha pitti as ottklos Egek 0 rtonetbot KI EÉKKttosek ii erővetéo len, 
art 






Stored Procedures 
Views 





CustomerDemographics 
Customers 

Employees 
EmployeeT errtories 
Order Detads 
Orders 
Products 
Region 
Shippers 
Suppliers 
Temitories 
CustOrderHist 


















A publikáció varázslómentes, kézi módosítása 


OK, majd futtassuk le újra a Snapshot aztán pedig a disztribú- 
ciós ügynököt! Ezúttal sikerrel járunk. Az ügynök history-jét át- 
tekintve megvizsgálhatjuk milyen lépések zajlottak le. 


Latest History of Distribution Agent 











Pubiizher: HARPISOLT Agent name: ÜLT NodherdCSHARPZ 

Pubbcaton omega lemsaeton MT 

Stamlimes — f2OG3OT0SZZ2A5B7A7 Commandz B 

Endüme  fő0030T0s2a23030sI Delyvenyrate— E3XIO000 emdí/sec 

Duzatorc [00-00-11 Latenoy me ú 
nlhszsz sent 2] Boz 

ÍGE Bukk copied data into table Categores" (B row) 20030108 232202.90 

HB Bukk copying data into table Categories" 2003010szazaoasz Hete] 


20030108 23290353 
20030108 23.2900.82( 
20030108 2323-00.57( 
20030108 2228.0051-. 
20030108 232800. 44 
20030108 23.2800.32( 
20030108 232800.25( 


szszai se Estsgeül] 


EH Bulk copied data into table "Customer" (7 tows) 
EB Bukk copying data into table Customers" 

EB Applied sciipt Customers Z6.idő 

EB Applied script Categoriez 22id( 

ER Applied script Fiegion, 16idk" 

EP Applied script Terrtorez 10id 

EB Applied script Products Gide 

BA Applied script Orders. 2idhé 

a 








E A replikáció sikeres lépései 


tech.net wWw.gR dá já w 


Nézzünk bele a céladatbázisba: 





ESETET eat tea 
JT console Window Help 
Ain Yew Tods [] € 5.[€lmal mal 
lElAl 8 8 lg 


Tree 










ISOL Server Enterprise Manager 




















53-14 Northwind 
























E-ÍJ NorthwindRepi 
8 Diagrams 
Tables 
6" Views 
HZ stored Procedures 
Users 
Bos (Eldtproperties — dbo System 
ss Esysusers dbo System 
CH Defauts systypes bo Syatom 
User Defined Data Tyi 
EL EGÉLSÉ Tali  sysreferences  dbo System 
-TÉ Ful-rext catalogs jelenét. TRRÁLAHBNAN 
-Í Nwcopy sysproperties  dbo System 





System 


a- Éd. petshan 1] JE svspermissions dbo 
a 





E A fogadó adatbázis megtelt tartalommal! 


A Customers táblát megtekintve boldogan látjuk, hogy a szűré- 
sünk is működik, csak az angol vásárlók replikálódtak át: 











WA1 10P 
EC2SNT 

WXI 6LT 

WX3 6FW 
PO31 7PJ 
SW7 1RZ 
OX15 4N8 


Region. 
120 Hanover 59. SNULL2 
Fauntleroy Circus." London ANULL2 
Berkeley Gardens 1 London SNULL3 





35King George London SNULL2 


Garden House Crov Cowes Isle of Wight 
South House 300 G London SNULL2 
90 Wadhurst Rd. London SNULL2 





E Jól látszik a vízszintes szűrés hatása az adatokon 


Hol járunk, hová tartunk? 


Áttekintettük a replikáció alapvető fogalmait, és összehoztuk a 
legegyszerűbb replikációfajtát, a Snapshot replikációt. A másik 
két replikáció ennél sokkal több meglepetést tartogat, amelye- 
ket idő hiányában most nem tárgyalunk. Aki szeretne igazán 
elmélyedni a témában, annak a 2591-es kódszámú Implemen- 
ting Replication Using Microsoft SOL Server 2000 háromnapos 
tanfolyamunkat ajánljuk. Én már 4 éve foglalkozom replikáci- 
óval, de a könyv megtanulása után sorban jöttek az ,aha, szó- 
val ezért van ez így" felismerések. Ezt kívánom kedves leendő 
hallgatóimnak is. 





A cikkben szereplő URL-ek: 


Soczó Zsolt MCSE, MCSD, MCAD, MCDBA, MCT 
Zsolt.Soczo€oönetacademia.NET 
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- Amikor elsül a kapanyél... 


SOL Injection 
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JL injection 


Amikor elsül a kapanyél... 


Ha egy nyilvános webhelyen csak a 80-as portot találjuk nyitva, emellett a kiszolgálóra folyamatosan 
felkerülnek a legfrissebb biztonsági javítások, nincs más hátra, a belső hálózaton található, eldugott 
SOL Servert kell meghekkelni, mégpedig az egyetlen lehetséges bejáraton, a 80-as porton, a futó we- 
balkalmazáson keresztül. , Csak" meg kell bolondítani a háttérben futó adatbázis-kiszolgálót, és 


tetszőleges adatokhoz hozzájuthatunk! 


Előzetes figyelmeztetés! 


1. Az alább közölt információk célja, hogy az adatbázisgaz- 
dák megismerkedjenek egy új típusú, testreszabottan rájuk 
leselkedő veszéllyel. Minden itt közölt adat megtalálható 
az Interneten, aki gonoszkodni akar, már lehet, hogy tud 
róla! 

2. Bár az összes példában Microsoft SOL Server a támadás 
célpontja, az SOL Injection platformfüggetlen technika: 
minden SOL-alapú adatbáziskezelő (Oracle, DB2, MySOL 
hogy csak néhány példát említsek) veszélyeztetett. 

3. Először a veszélyeket sorolom fel, hogy — érzékelve a prob- 
léma szerteágazó voltát — minél több fejlesztőt tudjak rá- 
venni a második részben felsorolt védekezési módszerek 
bevezetésére. 


Egy kis filozófia 


Az SOL injection esetében olyan , hibáról" van szó, mely mé- 
lyen az SOL-nyelvben, az SOL-koncepcióban gyökerezik. Eb- 
ben hasonlít a TCP/IP implementációs , hibájára" visszavezet- 
hető SYN Attack támadástípushoz. Nem történik semmi tör- 
vénytelen, csak éppen a helyzet egy kicsit szokatlan, s a gép — 
intelligencia híján — saját programozott szabályainak engedel- 
meskedve tönkreteszi önmagát. 

A mesterséges intelligencia feltalálásáig egyet tehetünk: a gép 
helyett, előre gondolkodunk, hogy öngyilkos helyzetekbe ne is 
kerülhessen szupermasinánk. Ezért kell ezt a cikket elolvasni 
és megtanulni! 

Háttérinfó 

Amikor Neumann János megalkotta a tárolt programvezérlésű 
számítógép elméleti modelljét, talán maga sem gondolta, mi- 
lyen galibát fog okozni negyven évvel később a rendszer ru- 
galmassága. Az tudniillik, hogy ugyanabban a memóriatérben 
tároljuk a végrehajtható kódot és az adatokat is. Ha a kettő 
összekeveredik, abból átláthatatlan galiba származik. 
Emlékezetes például az az eset, amikor az Intel kénytelen volt 
Pentium processzorait , visszahívni", gyakorlatilag lecserélni, 
mert bizonyos, a normális gyakorlatban soha elő nem forduló 
bájtsorozat végrehajtása után a processzor lefagyott. A hiba 
csak akkor állt elő, ha szándékosan előcsalogatták — vagy egy 
programozói hiba miatt adat futott kódként. 

Ennél már csak egy rosszabb eset fordulhat elő: amikor kódot 
tárolunk adatmezőben, adatbázisban, de onnan időnként 
mégiscsak elindul, vagyis kódot veszünk fel adatként. Ez a ka- 
varodás az SOL Injection hackertechnika lényege. Természe- 
tesen van ellene védekezés, de ennek kényelmetlensége foly- 
tán (sokat kell tenni érte) nem sok olyan adatbázis-alkalmazást 





láthatunk, amely következetesen, minden kódsorban hacker- 
álló. Előbb-utóbb minden alkalmazásfejlesztő elveszíti a türel- 
mét, és visszatér az SOL nyelv , normális" használatához. 


Hazai pályán 

Elsőként nyilván saját házunk táján kellene körülnézni, feltör- 
hető webalkalmazást keresni. Még egyszerűbb, ha építünk 
egy működő modellt, amelyen aztán kedvünkre rosszalkodha- 
tunk. Egy olyan weblapra van szükségünk, amelyik adatokat 
vár a látogatóktól. Ennek legegyszerűbb formája az alábbi, ret- 
tenetesen primitív HTML-űrlap, mely input.htm névre hallgat, 
és kódja letölthető az [1] címről, de itt is megmutatom: 


A http://localhost/input.htm - Micro... (EHEJEg 


Kedvencek Eszköz?! Ár 


3 


Nézet 


Fájl . Szerkesztés 


Orz- 9- Ad Ó 


] http: //localhostfinput.htm [7 ÉJ Ugrás Links.? 





E A világ legegyszerűbb webes adatbeviteli űrlapja 


Ilyen , bonyolultságú" űrlapokkal gyakran találkozunk kereső- 
rendszerek webhelyén. (A , vinet" szó egy, a Microsoft SOL 
Server Northwind nevű példaadatbázisában található fOrders] 
táblán futtatott lekérdezés paramétere lesz.) 

Nem szabad figyelmen kívül hagyni, hogy ez a mégoly primi- 
tív adatbevitel, majd a szűrés igen fontos , üzleti logikát" való- 
síthat meg, pusztán azáltal, hogy rejtve marad előttem más fel- 
használók adatterülete. Éppen ezért lesz szívszorító érzés, ami- 
kor kiderül, hogy milyen könnyen megkerülhető! 

A HTML-kód ennyi: 


chtml: 

cform action-"keress.asp" method-"get": 
cinput type-"text" name-"mezo"s 

cinput type-"submit" value-"Keress!": 
c/form: 

c/htmlz 


Ebből könnyedén kiolvasható, hogy az űrlap a ,keress.asp" ne- 
vű oldalnak adja majd át a paramétereket, mégpedig az URL- 
ben (GET metódus). A feldolgozást a keress.asp végzi, mely egy 
OleDB kapcsolaton keresztül nyaggatja az SOL Serveren a 
Northwind példaadatbázist. A jogosultságkérdést úgy oldottam 
meg, hogy beengedtem a Northwind adatbázisba az 
IUSR gepnev anonim webfelhasználót. Vitatható megoldás, 
viszont egyszerű és működik. Mások "sa" jogosultsággal futtat- 
ják a webalkalmazásaikat — ennél azért mégiscsak jobb az én 
módszerem! 


Íme az ASP-kód (a sorok számozása csak a magyarázatok 
megkönnyítése miatt került oda, nem Commodore Basicról 
van szó): 


chtmlz 

ch1:A keresett elemek:c/h1lz 

cb 

set conn-server.createobject("ADODB.Connection") 
conn.provider-" saloledb" 

conn.open "server-brokkoli;Database-northwind; 
4  Trusted, Connectionzyes" 

7 salstring-"SELECT $ FROM orders WHERE 
$ customerid-"" 4 reguest("mezo") a"t" 
8 set rs-conn.execute(salstring) $2 

9 ctable border-"1"5 

10 csdo while not rs.eof$z 

JELES e 

12 c$for each f in rs.fields$z 

13 ctds 

14 c$response.write f$z 

15 c/tdz 

16 c$next 

A rs.movenext$z 

18 c/tr: 

19 -c$loop$z 

20 c/tablesz 

21 c/htmlz 


OV UA UV FR 


A negyedik sorban alkotok egy ADODB.Connection objektu- 
mot, amit az ötödik-hatodik sorban paraméterezek fel. A hete- 
dik sorban forrasztom egybe az adatbázis-lekérdezést a keresé- 
si paraméterrel, majd a nyolcadik sorban hajtatom végre az 
SOL-parancsot. A további sorok az eredményhalmaz táblázat- 
ba tuszkolására szolgálnak, érdektelenek. Talán csak annyit, 
hogy a kód univerzális, mivel nem név szerint, hanem a Fields 
kollekció alapján pakolja táblázatba az adatokat. Beszédes ne- 
vű f segédváltozóm erre a célra szolgál. 


Íme a válasz a lekérdezésre (a táblázatban olvasható az a szó 
(VINETJ], amelyre rákerestünk): 


E TT AT TSAe e Te TÁ Ae öle LÖ LETELT ŐRB (EH1Eg 
Fájl Szerkesztés Nézet Kedvencek Eszközök Súgó 


D vsz " E - [9 [d Eh D keresés Sz kedvencek 


cím [6] http: /localhostjkeress. aspt?mezo—vinet 


A keresett elemek: 





he 


! ! 
10248 INET [5 7/4/1996 [9/1/1996 716/1996 f 32.38 falcools 
IT 
l l 


l Chevalit 


kel 
10274 ÍVINET! 





w k [s et 
8/16/1996 1116.01 lalcools 64 
] [1 





E A keress.asp egyszerűen táblázatba helyezi a lekérde- 
zés eredményét, bármi legyen is az 





Ez a kód is letölthető az [1] címről. Most már minden 
készen áll az SOL Server megkínzásához. 


Az SOL injection technika azt a tényt használja ki, 

hogy adatbázis-alkalmazásaink az esetek elsöprő 
többségében dinamikusan, röptében előállított SOL-paran- 
csokkal dolgoznak, ezzel vezérlik a központi adatbáziskezelőt. 
Nincs más dolgunk, mint egy kiszemelt adatbeviteli űrlap be- 
menő paramétereit úgy módosítani, hogy a webkiszolgáló által 
összeállított SOL-utasítás tartalmazza az általunk futtatni kívánt 
parancsot, vagy ha ez nem megy, legalább vakvágányra fusson 
a lekérdezés. 


Direkt befecskendezés 


Elsőként próbáljunk meg foglalt szavakat bevinni az inputme- 
zőbe, mondjuk biggyesszünk egy OR szócskát a keresett adat 
mögé, így: 


vinet OR 


Ha most megnyomjuk a Keress! gombot, és a lekérdezés meg- 
borul, úgynevezett direkt befecskendezési lehetőségre buk- 
kantunk, azaz a webalkalmazás úgy fűzi össze az SOL-paran- 
csot, hogy amit a beviteli mezőbe írunk, közvetlenül a parancs 
részévé válik. Ez tipikusan akkor fordul elő, ha a bevitt érték 
numerikus, mert ebben az esetben az adat (és további huncut- 
ságaink) közvetlenül az SOL-parancsba kerül. 

A mi esetünkben azonban a kód úgy dolgozik, hogy az alábbi 
sablonba, a ... helyére, egyszeres macskakörmök közé illeszti 
a felhasználó által megadott bemenő adatokat, így a közvetlen 
parancsbevitel meghiúsul: 


SELECT $ FROM orders WHERE customerid - !...! 


Ebből a fenti próbálkozás hatására a következő SOL-lekérde- 
zés születik: 


SELECT $ FROM orders WHERE customerid - "vinet OR!" 


Ez egy érvényes, bár valószínűleg üres halmazt visszaadó le- 
kérdezés, tehát a direkt SOL-befecskendezés ez esetben nem 
jött össze, de egy kis ravaszsággal jócskán fordíthatunk az állá- 
son (lásd később). 

Jegyezzük meg, hogy az űrlapok nemcsak látható, hanem rejtett 
mezőket is tartalmazhatnak (egy-egy azonosító Ipl. ProductID] 
vagy hasonló adat átvitelére). Ezek a numerikus adatok általá- 
ban alkalmasak közvetlen SOL-parancsok bevitelére, mivel a 
számokat macskakörmök nélkül, közvetlenül kell beírni a 
WHERE feltételbe. 


Ugyanilyen veszélyeztetett területnek számítanak a kiszolgáló- 
oldali munkamenet (session) vagy alkalamzás (application) 
változók, mert ezek sütibe (cookie) csomagolva bizony meg- 
fordulnak a felhasználók böngészőjében, és egy kis piszkálga- 
tással viszonylag könnyen hamisíthatók. 

Nyissuk meg a letöltött átmeneti fájlok könyvtárát (IEEszközö- 
kinternetbeállításokBeállításokFájlok megtekintése), és vá- 
lasszunk egy tetszőleges sütit (cookie), hogy megvizsgálhassuk, 
milyen adatok vannak benne? Meglepő, hogy mennyi, és mi- 
lyen régi sütik tanyáznak az ember gépén! Tavaly októberben 
például a MÁV internetes keresőjét (www.elvira.hu) használ- 
tam egy esetben, hálából kaptam tőlük egy sütit, amely így 
kezdődik: 
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vid j 
821553017 
"www.elvira.hu/ 


Itt a példa a numerikus inputra, amely reagálhat a 
közvetlen SOL injection-támadásra. Az SOL injectionban az a 
nagyszerű, hogy platformfüggetlen. Nem kell tudnom, milyen 
adatbáziskezelő dolgozik az Elvira mögött, elég, ha az ANSI 
SOL nyelvet ismerem! — 

A második sorban a felhasználói azonosítóm (821553017) lát- 
ható. Ha emögé odabiggyesztünk egy foglalt SOL-szót, kiderül, 
hogy érzékeny-e Elvira a direkt befecskendezésre. 


Most pedig térjünk át arra az esetre, amikor a közvetlen parancs- 
beirkálás az SOL-parancs összeállítása folytán nem sikerülhet! 


Indirekt befecskendezés 


A megoldás rendkívül egyszerű: hatástalanítanunk kell a szá- 
munkra felesleges jeleket (egyszeres macskakörmök, zárójelek 
stb.). Ennek érdekében úgy töltjük fel az adatbeviteli mezőt, 
hogy az ki is elégíti az SOL utasítást, meg nem is. Vagy inkább 
túlságosan is kielégíti, hogy aztán a saját kódunkat is beilleszt- 
hessük. Írjuk be például ezt: 


Lássuk, ebből a furfangos inputból milyen SOL-utasítást farag 
szerencsétlen flótás ASP-lapunk: 





SELECT $t FROM orders WHERE customerid - 
b "yvinet" or !a"z"a! 


Ebből az aláhúzott karaktereket volt szerencsénk hozzátenni a 
teljes produktumhoz. 

Hoppá! Ez egy igen érdekes lekérdezés lett! Ha jobban végig- 
gondoljuk, kiderül, hogy ez az összes rekordot vissza fogja ad- 
ni a táblából, nemcsak azokat, amelyeket a programozó ne- 
künk szánt! Az előző lapon beharangozott business logic-meg- 
kerülés bekövetkezett: az összes rekord nyilván tartalmazza 
azokat a sorokat is, amelyekhez elvileg semmi közöm. Adott 
esetben a versenytársaim adataihoz is hozzáférhetek! 


No komment 


Bonyolultabb SOL-string esetén nem biztos, hogy ilyen egysze- 
rűen célt érünk. Lehetséges, hogy nem egy, hanem hatvanhat 
inputmezőnk van, és ezek mindegyike más-más típusú. Nem 
könnyű eltalálni az egyszeres macskakörmök helyes arányát. 
Ezen a problémán segíthet a komment-technika. Köztudott, 
hogy a kettősmínusz (--) az SOL Server egyik komment-jelzője. 
Ha egy sorban előfordul, minden utána következő karakter 
megjegyzéssé válik. (Más adatbáziskiszolgálókon más a kom- 
ment jele!) 

Ha tehát sokadik macskaköröm-kísérletünk sem sikerül, vagy 
nem akarunk 66 mezőt kitölteni, próbáljuk ki a következő be- 


menetet: 
Keress! 


Amiből a szorgos ASP-lap a következő SOL-parancsot fűzi 
össze: 











vinet" or151-- 





SELECT $t FROM orders WHERE customerid - 
H "vinet" or 1-1--! 


Vagyis a lekérdezés végétől egy huszárvágással megszabadul- 
tunk. Maga a lekérdezés egyébként ismétcsak minden sort 
visszaad. 

Most azonban térjünk rá az eddigiek gyakorlati felhasználásá- 
ra. Vannak emberek, akik ingyen látogatják a pénzes webhe- 
lyeket (pornósite stb.). Ha nem a főnök cimborái, akkor való- 
színűleg SOL injektorok. A jelszavas webhelyek jelentős részé- 
nél a felhasználók azonosítása adatbázisból történik. Két me- 
zőt kell kitölteni: név és jelszó. Azután a háttérben egy, az 
alábbihoz hasonló SOL-lekérdezés sikeressége (van-e találat?) 
alapján dől el, bejutunk-e, vagy sem: 


salstring - "SELECT username FROM users WHERE 
$ username - "!" 4 name 4 "" and password — !" 4 
$ strPassword 4 "!" 


Itt a fenti trükköt annyival kell megtoldani, hogy hatástalaníta- 
ni kell egy AND műveletet. Ha a bejelentkezési űrlapon mind- 
két mezőbe ezt írjuk: 


kukucs" or ""z! 


... a lekérdezés így alakul: 


SELECT username FROM Users WHERE username "kukucs! 
Zorro HZ randi passwórot si" kükücÉÍTOS A NVZY 





Vagyis az ÉS műveletet egy mindig igaz kifejezés segítségével 
hatástalanítottuk. (Tulajdonképpen az a lényeg, hogy a WHERE 
feltétel legutolsó kifejezése igaz legyen.) 


UNION ALL 


Egyetlen tábla adatainak lekérdezése nem biztos, hogy elegen- 
dő egy minden adatra éhes hacker számára. Ha talált egy 
,megvezérelhető" lekérdezést, azon keresztül gyakorlatilag az 
adatbázis összes táblájának összes adata lekérdezhető. 
Hogyan? Talán át lehet írni a webkiszolgálón a lekérdezéseket? 
Nos, azt éppen nem, de a kommentes trükk segítségével tet- 
szőleges további lekérdezések futtatására adhatunk parancsot. 
A titok nyitja a UNION operátor, amivel két SOL-lekérdezés 
eredményét fűzhetjük össze. Például: 


SELECT Idopont, Vasarlas FROM Vasarlasok 


UNION ALL 
SELECT Idopont, Vasarlas FROM Vasarlasok Archiv 


Ebben az esetben a UNION (ALL) segítségével a jelenlegi és a 
korábbi vásárlások adatait egyetlen kimenetben összesítettem. 
A sikeres UNION-művelet egyetlen feltétele (a megfelelő jogo- 
sultságon túl), hogy mindkét SELECT azonos számú és típusú 
mezőkből épüljön fel. A mi esetünkben a lekérdezés tizennégy 
(14) mezőt ad vissza, tehát bármit is biggyesztünk utána, annak 
ugyanennyi, 14 darab mezőt kell visszaadnia, ráadásul típus- 
helyesen. 

Ha a sysobjects tábla tartalmára volnánk kíváncsiak, a 


SELECT $ FROM sysobjects 


lekérdezésnek is pontosan 14 mezősnek kell lennie ahhoz, 
hogy hozzá lehessen fűzni az eredeti lekérdezéshez. 
Ennek legegyszerűbb módja talán az alábbi lekérdezés: 


SELECT name, null, null, null, null, null, null, 
null, null, null, null, null, null, null FROM 
sysobjects 


Tizennégy mezője van ugyebár? S ebből 13 garantáltan típus- 
helyes, mert a NULL minden más mezőtípusnak , értéke" lehet. 
Az egyetlen bizonytalan tényező pontosan a legelső, s egyben 
egyetlen értelmes mező (a name) típushelyessége, de hátha 
megsegít a Hackerek Istene, adjuk be az adatbeviteli mezőbe 
az alábbi karaktersorozatot: 


dgag " UNION ALL SELECT name, null, null, null, 
HUJ zs ELER SÜG ANT SEÁGN E ELL SALE 
null, null FROM sysobjects -- 


Ennek hatására az ASP-lap az alábbi lekérdezést juttatja el az 
SOL Serverhez (aláhúztam az injektumo0: 


select $ from orders where customerid-!"agg ! UNION . 
ALL SELECT name, null, null, null, null, null, 

1 nm a. ni null, null 
EROM sysobjects ——! 











És a várva várt válasz: 


Fájl . Szerkesztés Nézet Kedvencek Eszközök Súgó 


OD vs "0 ke PP keresés 4 kedvencek 





The page cannot be displayed  [fwame 7 
HTTP 500.100 - Internal Server Error - ASP erro [/docAuhobeical ist of products 
Internet Information Services do" category Sales for 1997 


e Error Type: 
Microsoft OLE DB Provider for SOL Server (0x80040E07) 
Syntax error converting the nvarchar value[/Alphabetical list of products" 
to a column of data type int, 
Zkeress.asp, line 9 

















E Egy sikertelen lekérdezés is lehet sikeres. Figyeljünk a 
beszédes hibaüzenetre! 


Ez a lekérdezés ugyan nem futott le, de a kapott hibaüzenet 
több olyan információt is tartalmaz, aminek nagy hasznát 
vesszük. Először is kiderült, hogy a legelső mező egész (int) tí- 
pusú, hisz az üzenet szerint a hiba oka, hogy egy nvarchar tí- 
pusú értéket (a name mező aktuális értékét) nem sikerült int-té 
alakítani. 

A bekeretezett "Alphabetical list of products" pedig nem más, 
mint a sysobjects tábla legelső sorának name-értéke! Bizonyí- 
tékképpen odahamisítottam a képernyőképre az SOL Enterpri- 
se Manager ablakának nézeteket ábrázoló első két sorát. 

Ha valaki ennyivel is megelégszik, akár egy seregnyi hibás le- 
kérdezés és hibaüzenet segítségével is felderítheti bármelyik 
tábla bármelyik mezőjének tartalmát, csak egy kicsit hossza- 
dalmas lesz az eljárás. Ehelyett (felismerve, hogy a VINET szót 
tartalmazó mező nyilván karakteres típusú) alakítsuk át úgy a 
lekérdezést, hogy az első két mezőt felcseréljük, vagyis a na- 
me mező értéke a VINET-mezőbe kerül (aláhúztam a válto- 
zást: 


daaa ! UNION ALL SELECT null, name, null, null, 
null, null, null, null, null, null, null, null, 
null, null FROM sysobjects -- 


Ez már szépen lefut, és visszaadja a sysobject összes bejegyzé- 
sét. Táblák, indexek, nézetek, megszorítások (constraint) neve- 
it láthatjuk szépen sorban: 





j 


Eájl Szerkesztés Nézet Kedvencek Eszközök Súgó 


Ora O - E D EH A terssés SZekzárnak 


Employee Sales by County 
Employees 

EmployeeTerritories 

FK. CustomerCustomerDemo k 

FK CustomerCustomerDemo Custorners 


FK Employees Employees 


FK EmployeeTerritorie: Employees 


E Furfangos lekérdezésünkkel kilistáztuk a sysobjects táb- 
la tartalmát 


A sysobjects tábla lekérdezésével eljutottunk a ,tetszőleges 
adat", mint cél eléréséhez. Innen már elengedett kézzel hozzá 
lehet jutni akár az adatbázisterv grafikus megjelenítéséhez is. 
És még mindig nincs vége! 


Pontosvessző 


További érdekes lehetőség egy, az eredeti lekérdezéstől telje- 
sen független parancs lefuttatása szegény kis űrlapunk segítsé- 
gével. Ehhez csak annyit kell tudnunk, hogy az SOL-nyelv le- 
hetővé teszi, hogy egy karakterláncban több parancsot is elhe- 
lyezzünk. (Tulajdonképpen a pontosvessző csak ahhoz kell, 
hogy a parancsértelmező [parser] egyértelműen el tudja vá- 
lasztani egymástól az egymást követő parancsokat. Ha az elvá- 
lasztás egyértelmű, még pontosvessző sem kell!) 

Ha tudjuk az adatbázis objektumainak nevét (az imént kérdez- 
tük le a sysobjects táblából), mókás tettekre nyílik lehetőség a 
DROP TABLE utasítás felhasználásával: 


Legnagyobb sajnálatomra ez az utasítás csak megfelelő jogo- 
sultságok birtokában fogja végrehajtani a táblatörlést. 
Az INSERT, UPDATE, DELETE parancsokat viszont biztosan 
végrehajtja, hisz a webalkalmazás normális működéséhez 
szükség lehet ezekre a jogosultságokra. Ne kicsinyeskedjünk, 
javaslom a BULK INSERT és a DELETE utasításokat, utóbbit le- 
hetőleg WHERE feltétel nélkül! Így derül ki, vajon védik-e re- 
ferenciális integritási szabályok az adatainkat, vagy éppen a 
hackernek segítenek. 
TA Ha nincs megfelelő referenciális integritási szabály a 
táblák közt, a kipécézett tábla összes sora törlődik. 
JA Ha megvannak a referenciális integritási szabályok, de 
beállítottuk a CASCADE DELETE opciót is, nemcsak ez 
az egy, hanem az összes gyermektábla is kiürül! 





Ha meg szeretnénk tudni, rendszergazdai erősséggel rendelke- 
zünk-e, adjuk be a következő inputot: 


nesze" SHUTDOWN-- 


Kell-e magyaráznom? 


xp. Cmdshell 


Ha az előző, leállításos móka sikerült, további lehetőségek 
nyíltak ki előttünk, hisz rendszeradminisztrátorként a világon 
mindenre rá tudjuk venni az SOL Servert. Az xp. CmdsShell kül- 


- nonJalui 105 / 
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" Amikor elsül a kapanyél... 
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ső tárolt eljárás segítségével operációs rendszer-pa- 
rancsokat hajtathatunk végre SYSTEM jogosultsággal. 
sSajnos" egyszerű adatbázisfelhasználók csak akkor 
futtathatják, ha előtte valaki beállított az SOL Server 
Agenten egy úgynevezett Proxy Accountot. 


xp. RegXXXX 


Ha valaki az Online Book tanulmányozásával deríti fel az SOL 
Server képességeit, sok mindent nem fog megtudni. Az alábbi 
tárolt eljárások például egyáltalán nem szerepelnek a doku- 
mentációban; a Master adatbázis átkutatásával viszont rájuk 
bukkanunk. Először a bármelyik felhasználó számára enge- 
délyezett xp regread nevű, regisztrációs adatbázis-olvasó tá- 
rolt eljárást próbáljuk ki! 


exec master. .xp. regread HKEY LOCAL MACHINE, 
8. "SYSTEMXCurrentControlSetiServicest 
4 lanmanserverWparameters!, "nullsessionshares" 


Ez a lekérdezés kilistázza, melyik Windows-megosztások érhe- 
tők el anonim csatlakozással, s ezzel értékes információt ad to- 
vábbi, hagyományos hackelési lépések megtételéhez. A továb- 
bi dokumentálatlan registry-matató tárolt eljárások csak rend- 
szergazdai jogosultság birtokában használhatók: 


xp. regaddmultistring 
xp. regdeletekey 

xp. regdeletevalue 

xp. regenumkeys 

xp. regenumvalues 

xp. regremovemultistring 
xp. regwrite 


BEBEBBB 


További , rejtett" tárolt eljárások 


További huncut gondolataink támadhatnak a dokumentálatlan 
tárolt eljárások között tallózva a Master adatbázisban ... 





xp. ServiceControl Windows-szolgáltatások elindítása, 
leállítása (ezt használja 


a SHUTDOWN-parancs) 
Rendelkezésre álló meghajtók 
betűjelének, szabad területének és 
típusának kilistázása 





xp. availablemedia 





xp..dirtree Egy meghajtó teljes könyvtárszer- 
kezetének felderítése. Nem igényel 
adminjogokat! 
ODBC-adatforrások lekérdezése 
Az SOL Server biztonsági 


üzemmódjának lekérdezése 





xp.enumdsn 
xp. loginconfig 








(Tömörített fájlok készítése. 

! Paraméterek nélkül futtatva kiírja 

ja használati utasítást 

Az SOL Server által elérhető tartomá- 
! nyok listája. Nem igényel adminjogokat! 
KILL.EXE 


xp.makecab 





xp.ntsec enumdomains 








xp.terminate process 





Talán ennyi is elég lesz ahhoz, hogy mindenki sürgősen hoz- 
zálásson adatbázis-alkalmazásainak befoltozásához. Vagy 
mégsem? A kedvencemet még hadd mutassam meg, mielőtt 
végleg bezárjuk a rémségek kicsiny boltját, és rátérünk a meg- 
oldási lehetőségekre. Szép példája a COM-objektumok segít- 
ségével megvalósítható funkcionalitásnak. Ez nem más, mint... 


A beszélő SOL Server 


Ha - netalán — az SOL Server-gépen telepítve lenne a Speech 
API (általában nincs), az alábbi kódrészlettel beszédre bírhat- 
nánk, pusztán a legelső oldalon mutatott HTML-űrlap szorgos 
feltöltésével: 


declare E€hang int 

exec sp. oacreate "speech.voicetext!, EGhang out 
exec sp. oamethod Eéhang, !register!, NULL, 

B "kutya", "fule" 

exec sp. oasetproperty Ehang, 
exec sp. oamethod Eehang, "speak! , 
$ "subidubidu!, 528 


"speed", 150 
NULL, 


Ez a néhány sor arra készteti az SOL Servert, hogy azt mondja: 
subidubidú. Az angol Speech API ezt így ejti ki: szjubájdubidú. 
Ennyit a veszélyekről. Most pedig következzenek a védekezé- 
si lehetőségek! 


Védekezési lehetőségek 


Kézenfekvőnek tűnik a bejövő adatok szűrése (erre mindjárt 
adok is néhány tippet), de ne feledjük, hogy ezzel csak újabb 
szabályokat adunk a buta gépnek, amit szintén ostobán, öntu- 
datlanul fog alkalmazni. Ha van két szabályunk, például, hogy 
a gyufa lángja fényt ad, valamint hogy a benzintankban sötét 
van, egy számítógép ezt a kettőt gyönyörűen összepárosítja, és 
benéz a gyufával a benzintartályba. Próbálkozhatunk kivétel- 
gyűjtemény felsorolásával (világíts gyufával, kivéve ha egy 
benzintartályban van sötét), de az esetek többségében a kivé- 
tellista végtelen hosszú. Ha azt kellene felsorolni, ki nem hord 
zoknit, bele kellene írni a teljes állatvilágot, kivéve (a kivétel 
kivétele!) a cirkuszi zebrát. Ilyen helyzetekben csak a mester- 
séges intelligencia segítene, de az — egyelőre — nem létezik. De 
lássuk a szabályalapú védekezést. Ne várjunk tőle túl sokat... 


1. védekezési mód: eszképelés 


Ez az eljárás nem más, mint a bemenő adatokban esetleg elő- 
forduló egyszeres macskakörmök megduplázása, ettől ugyanis 
adattá válik maga a jel is. Például így: 


function escape( input ) 


input 5 réplace(input, "s; "iua) 
escape - input 
end function § 


Éles példa: ha a hacker ezzel próbálkozik: 


subidubi!; SHUTDOWN -- 


Az egyszeres macskaköröm megduplázásával a teljes string, 
subidubitól a mínuszmínuszig bekerül az adatmezőbe, hisz ki- 
húztuk a macskaköröm méregfogát (brutális képzavar). És az 
időzített bomba elkezd ketyegni... 

Kibúvó: az egyszeressé tett macskaköröm utólag is gyilkos ha- 
tású lehet. A fenti SHUTDOWN parancs ezúttal álomba szen- 
derült, de akármikor féltámadhat: például ha az adatmezőből 
bármikor később stringkolbászolással állítunk elő parancsot 
(amikor az adatbázisgazda sa-jogokkal fésülgeti az adatokat). 


2. védekezési mód: törlés 


Esetleg megpróbálkozhatunk a , veszélyes" karakterek és a fog- 
lalt szavak törlésével is. Az egyszeres macskaköröm a magyar 
nyelvben gyakorlatilag nem létezik, tehát akár törölhetjük is. 
További ,gonosz" karakterek: pontosvessző, mínuszmínusz, 
foglalt szavak stb. (végtelen lista). A foglalt szavak törlése pedig 
egyenesen reménytelen feladat. Ráadásul nem is célravezető. 


Kibúvók: 
JA Ha - az adatok elemzésével - felismerjük a törlési sza- 
bályt, alkothatunk olyan stringeket, amelyeket pont a 
törlés javít ki! Lásd: 


DR"!OP TA"BLE Adatok -!- 


TA A veszélyes karakterek char() függvénnyel is bevihetők 
TA A stringeket hexadecimális formában is meg lehet adni. 
Lásd, (és próbáld ki!) ezt: 


declare Eduma varchar(8000) 
SELECT Eduma - 0x73656c65637420404076657273696f6e 
exec (Eeduma) 


3. védekezési mód: a stringkolbász vége 


Egyelőre egyetlen hathatós megoldásnak az tűnik, ha száműz- 
zük programozói eszköztárunkból a röptében, stringfűzőcské- 
vel készített SOL-parancsokat. Ez nem fog menni egyik napról 
a másikra, és még akkor is rengeteg régi kód marad, amit sen- 
ki nem fog kijavítani. 

Mit lehet tenni a dinamikus parancsok használata helyett? Hisz 
azért rakjuk össze menet közben a parancsot, mert minden al- 
kalommal más eredményhalmazra lövünk, más lekérdezést 
szeretnénk futtatni. A tárolt eljárásokat pont nekünk találták ki. 
Egy-két bemenő paraméter segítségével vezérelhető a benne 
lévő SOL-kód, de vigyázat! A tárolt eljárások használata önma- 
gában NEM jó megoldás. Ha továbbra is dinamikusan, kódból 
pakoljuk össze az SOL-stringet, semmivel sem jutunk távolabb 
a becsapható alkalmazástól! 

Ne mi fűzzük a stringet! Bízzuk ezt az ügyféloldali csatolóra, 
az ADO-ra! Az alábbi kódrészlet egy ilyen megoldást mutat. 
Először is alkossuk meg a lekérdezést az SOL Serveren, para- 
méterezett tárolt eljárás formájában: 


CREATE PROCEDURE Kereses ébe varchar(55) AS 
select § from orders where customerid-Eébe 


Adjunk futtatási jogot megfontolt módon — mondjuk — minden- 
kinek: 


GRANT EXECUTE ON Kereses TO Public 


Majd alakítsuk át a keres.asp-ot oly módon, hogy paraméter- 
ként adagoljuk be egy ADODB.Command objektumnak az in- 
putot. Sajnos a paraméterek használatához szükségünk lesz az 
ADO-konstansok használatára, ezért másoljuk az ASP-lapunk- 
kal közös könyvtárba az adovbs.inc fájlt a CNXProgram Files 
Common FilesXSystemvado könyvtárból, majd az ASP-lap leg- 
felső sorában töltsük is be: 


c1-- tinclude virtual-"adovbs.inc" ——5 


Ez a sor azért szükséges, mert nélküle nem hivatkoz- 
hatunk név szerint az alább használt ADO-konstan- 
sokra (pl. advarChar). Ezután a kód úgy módosul, 
hogy létrehozunk egy ADODB.Command objektumot (mert ez 
tud tárolt eljárást értelmesen meghívni), majd beállítjuk, hogy 
használja a meglévő ,conn" nevű kapcsolatot, végül elmesél- 
jük neki, hogy a ,Kereses" nevű tárolt eljárás (adStoredProc) 
végrehajtásával szeretnénk megbízni: 


set cmd-server.createobject("ADODB.Command" ) 

Set cmd.ActiveConnection - conn 

cmd.CommandText - "Kereses" 

cmd.CommandType - adCmdStoredProc 

Külön kaland a paraméter(ek) beállítása, ez ugyanis egy típus- 
függő paraméterobjektum létrehozásával történik meg. 

Set param - Cmd.CreateParameter ( "CustomerID" , 


adVarChar, adParaminput, 55, reguest—("mezo")) 
Cmd.Parameters.Append param 


És már futhat is a félbolond-biztos webalkalmazás. (Macskakö- 
röm-ügyben az 1. védekezést valósítja meg, tehát időzített 
bomba!) Teljeskörű megoldás majd a mesterséges intelligenci- 
át alkalmazó parancsértelmezőktől várható... 


Fóti Marcell 

marcellfonetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


LESTE VT ÉLTő 


(11 http://technet.netacademia.net/download/SOLInjection 
[2] www.sglsecurity.com 
[3] Advanced SOL Injection In SOL Server Applications 


http://www.ngssoftware.com 


Merre E ke e 


SOL Workshop (12 óra) 
2072 -SOL Server 2000 rendszerfelügyelet (40 óra) 
2073 — Az SOL Server 2000.programozása (40 óra) 
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Hethrademia Nagylexikon 


T, mint tartomány 


Napjaink nagyvállalatainál az informatika jelenléte nem is kérdéses. Sokan tudják, hogy egy tartomány 
mire való, mit tárolhatunk benne, de kevesen gondolják végig, hogy miért szükségszerű a használatuk 
még abban az esetben is, ha — mint oly sok cégnél — sem adattárolási lehetőségeiket, sem lekérdezhe- 
tőségüket nem használjuk ki. Ebben a szócikkben a tartományok (címtárak) használatát kikényszerítő 


belső erőket elemezzük. 


Néhány feladat, ami pár fős cégeknél nem biztos, hogy tarto- 
mányért kiált, több száz munkaállomásból álló hálózatok ese- 
tén nem látható el megfelelő eszközök nélkül: fel sem merül- 
het például, hogy az adatok jogosulatlan hozzáférését baráti 
beszélgetéses módszerrel tiltsuk le, vagy a dolgozók e-mail cí- 
meit Excel fájlokban adjuk közre. Ennél erőteljesebb, automa- 
tikus, önkarbantartó módszerekre van szükség. 

Minden nagyvállalati szolgáltatás alapja a felhasználók töké- 
letes azonosítása. Ehhez egyfelől kötelező bejelentkezésre, 
másfelől a felhasználók által megjegyzendő adatok minimali- 
zálására van szükség. A kötelező bejelentkezés NT alapú 
munkaállomások (Windows NT 4.0 Workstation, Windows 
2000 Professional és Windows XP) telepítésével könnyedén 
biztosítható. 

Ennél sokkal nehezebb feladat a megjegyzendő adatok halma- 
zának redukálása. A kötelező bejelentkezést elvileg ezen ope- 
rációs rendszerek mini-címtáraira (SAM) is építhetjük: minden 
számítógépre fel lehet venni annak az egy személynek a (beje- 
lentkezési) nevét, aki azt használni fogja. Hamarosan látni fog- 
juk, hogy ez a megoldás káoszba torkollik. Ha nem kérünk a 
központi tartomány szolgáltatásaiból, hanem munkacsoport- 
ban (workgroup) üzemeltetjük számítógépeinket, a felhaszná- 
lók felvitele sem központosítható. Munkacsoportos kiépítésben 
annyi címtár-szigetünk lesz, ahány munkaállomás a hálózaton 
található. Hol itt a hiba? 

A rendszertervben. Felhasználóink ugyanis előbb-utóbb ráéb- 
rednek a hálózat nyújtotta lehetőségekre, és csatlakozni pró- 
bálnak egy megosztott nyomtatóra. Igen ám, de kinek a nevé- 
ben, ha a nyomtatót megosztó gép , címtárában" nincs más fel- 
használó felvéve, mint aki ott ül? Hiába látjuk a hálózaton az 
erőforrást, a kötelező bejelentkezésen nem jutunk át, hacsak 
az alábbi ablakot (Connect As...) ki nem töltjük olyan adatok- 
kal, amit a szomszéd gép elfogad. 


Connect to platan.netacademia.fm 


Connecting to platan 





User name: 


Password: 





[Remember my password 








E! Kapcsolódás előtti azonosítás. Hol a címtár? 


Mit is fogad el? Általa ismert neveket és jelszavakat. Ismerünk 
ilyen nevet? Úgy hívják: Administrator?? 
A név-jelszó ablak megjelenése három módon kerülhető el: 

A Ha , odaát" engedélyezik a Guest felhasználót. (Mind a 
150 gépen? Ez hiperbiztonságos lenne ám! Azonnal fe- 
lejtsék el!) 

A Ha , odaát" felvesszük a mi felhasználónkat a mini- 
címtárba (SAM). Ezzel kezdetét veszi a káosz, a fel- 
használók duplikálása, triplikálása, 150-szerezése. Mi- 
után már minden gépen létrehoztuk ugyanazt a fel- 
használót, biztosan kitalálja valaki, hogy a jelszavakat 
háromhetenként meg kellene változtatni. No de 150 
mini-címtárban? 

JA Ha központosított felhasználói adatbázist vezetünk be: 
vagyis címtárat, Windows tartományt alkotunk, és eh- 
hez az összes munkaállomást csatlakoztatjuk. 

A központi címtár bevezetésével nemcsak a felhasználói fió- 
kok felvétele és karbantartása egyszerűsödik, hanem egységes 
házirendet, bejelentkezési parancsfájlokat stb. alkothatunk, és 
tehetünk kötelezővé. Emellett egy olyan rugalmas címtár, mint 
az Active Directory, számtalan más, a hitelesítésen messze túl- 
mutató szolgáltatást nyújt. 
Erről bővebben a 36. oldalon olvashatnak. 
További szócikkek kidolgozására (akár több száz, de csak vé- 
gigfutva az ABC-n: ADSI, BAP, CDO, DHCP, EFS, FTP, GPRS, 
HTTP, IKE, JScript, KMS, LFS, MAPI, NAT, OSPF, PPTP, OoS, 
RSA, SNMP, TAPI, UDDI, VIA, WOL, XSD, Zóna) vállalkozó- 
kat keresünk! 
Fóti Marcell 
marcellfonetacademia.net 
A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


Hálózat a 5000-ban 


A Windows XP kishálózatokra 
tervezett szolgáltatásai 


A Windows XP hálózati szolgáltatásai közt találunk jó pár olyan megoldást, melyek igencsak meg- 
könnyítik néhány számítógép behálózását és Internetre csatlakoztatását. A világ boldogabbik felén ezek 
a szolgáltatások az otthoni hálózat kialakításában segítenek — nálunk kisvállalatok vehetik hasznát! 


Az , önjáró" IP története 


Kezdetben vala IPX és NetBEUI, melyekkel gyermekjáték a há- 
lózatépítés, hisz címkiosztásuk automatikus. Azután lett 
TCP/IP, és címkiosztási zűrzavar. Ezen segített a DHCP Server, 
mely a Windows NT 3.5 Resource Kit részeként levette a cím- 
kezelés feladatát a vállunkról. Amikor a hálózatok eljutottak az 
amerikai háztartásokba, kiderült, hogy a DHCP sokkal bonyo- 
lultabb dolog annál, amit daddy képes lenne beüzemelni. 
Ismerkedjünk meg egy tipikus amerikai háztartás hálózatával. 
A családi ház kétszintes, a földszinten nappali, az emeleten há- 
lószobák. A nappali és a konyha Internetesítése már megtör- 
tént, most következnek a hálószobák. A földszinten van egy 8- 
portos hub, aminek minden csatlakozási pontja betelt. Az eme- 
leten is van már ethernet, mert a két gyerek így doomozik. Elő- 
ször nézzük meg részletesen, mitől is működik. 


Az APIPA (Automatic Private IP Adressing), automatikus privát 
IP-cím teszi lehetővé, hogy a gépek egymásra találjanak. Ez 
nem más, mint DHCP Server nélküli IP-cím , kiosztás". A háló- 
zatra kötött Windowsok — ha nem kapnak választ DHCP-kéré- 
seikre — kis idő elteltével automatikusan felvesznek egy hasra- 
ütéssel kiválaszott IP-címet a 169.254.x.y címtartományból. Ér- 
dekes mendemonda terjedt el arról, hogy ez a címtartomány a 
Microsoft ,ajándéka" a népnek, de némi utánajárással kiderül, 
hogy az APIPA az IEFT-nél alakulóban lévő szabványtervezet. 
Az alábbi ábrán egy tipikus APIPA-címet láthatunk. Az alapér- 
telmezett átjáró nincs kitöltve — ennek az információnak (infor- 
máció-hiánynak) a későbbiek során még lesz szerepe! 


169.254.25.129 
255.255.0.0 


Automatikus konfiguráció IP-címe . 
Alhálózati maszk. 
Alapértelmezett átjáró . 


Egy automatikusan generált APIPA IP-cím 


Az [1] címen a Zeroconf Reguirements foglalja össze, miért 
vált ez a téma olyan súlyúvá, hogy szabványt szenteljenek ne- 
ki. Idézek a draftból, hogy tudjuk, hol van szükség , önjáró" IP- 
cím kiosztásra: , home networks, automobile networks, airplane 
networks, or adhoc networks at conferences, emergency relief 
stations". 

(Az automobile network feltételezésem szerint az autóinkba 
beszerelt IP-alapú bigyók összessége. Elfogadom, hogy egy 
DHCP-kiszolgáló beszerelése a motortérbe (mert ugyan hova 
máshovaf] furcsa ötletnek tűnik.) A [2] címen olvasható draft 
adja meg az APIPA-címtartományt. 

Szépen működik is minden, amíg el nem fogy a nyolcportos 
hubban az összes lyuk, ám kénytelenek vagyunk mégegy háló- 
zatot csatlakoztatni. Az APIPA címek ugyanis nem routolhatók. 





(Mondhatja erre valaki, hogy vegyünk még egy hubot, dugjuk 
össze a kettőt, és kész. Vagy dobjuk ki az egyébként hibátlan 
8-portost, és vegyünk egy 16-ost. 


APIPA-hálózatok összekapcsolása 


Elfeledve a hubok egyszerű felfűzését további két út kínálkozik 
hálózataink összekapcsolására. Az egyik az útválasztás (rou- 
ter), a másik a híd (bridge). 

Az útválasztás akár még Windows XP-n is megvalósítható az 
alábbi regisztrációs kulcs 1-be billentésével: 


HKLMISYSTEMNCurrenmtControlSetNServicesiTcpipt 
S ParameterslIPEnableRouter 


Az APIPA IP-címekkel felvértezett gépek csak abban az esetben 

látnának át a túlsó hálózati szegmensre, ha 

1. alapértelmezett átjárójuk (Default Gateway) a routerként 
üzemelő cinkostárs Windows XP-re mutatna 

2. IP-címeik nem ugyanabba az alhálózatba (subnet) esnének. 


A két feltétel egyikének sem felel meg az APIPA-cím, tehát ha 
útválasztást használunk, át kell térnünk más IP-címekre, és el- 
veszítjük az eddigi kényelmes automatizmust. Az [1] címen ol- 
vasható draft szerzői is tisztában voltak a problémával, és a kis- 
hálózatok összekapcsolására hidat (bridge) javasolnak. Szeren- 
csére ilyet nem kell vásárolnunk, mert a Windows XP képes két 
hálózati kapcsolat ,áthidalására". Ehhez nem kell mást ten- 
nünk, mint kijelölni kettő (vagy több) hálózati kapcsolatot, és a 
gyorsmenüből kiválasztani a , Hídkapcsolatok" menüpontot. 
(Vagyis azt tanácsoljuk daddynek, hogy ne hubot, hanem egy 
plusz hálózati kártyát vásároljon, és szerelje be a nappaliban 
állomásozó PC-be.) 


9 tzmtmatás 19 Ctereet [atát mezét 3990 
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E Hídkapcsolat kialakí- 
tása két hálózati szeg- 
mens között 





Kevés merevlemez-teke- 
rés után... 


Hálózati híd 


ga Várjon, amíg a Windows létrehozza a kapcsolatok között a 
hálózati hidat... 





Létrejön a hídkapcsolat a két LAN között, s a két alhálózat gé- 
pei minden további nélkül látják egymást. Átjutnak a Broad- 
cast-üzenetek, és ezzel a NetBIOS-névfeloldás is működni 
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kezd. Egyszerű, de nagyszerű, és ráadásul kevésbé 
pazarolja a sávszélességet, mintha a hubokat össze- 
dugtuk volna, mert a hídon csak akkor kell átkülde- 
ni a csomagot, ha az valóban a túlpartra igyekszik. 
Áthidalással tulajdonképpen két fizikai alhálózat 
(subnet) olvasztható össze. Az összekötött szegmenseken 
azonos IP-cím használandó. E tulajdonság miatt néha gazda- 
ságosabb egy.híd, mint egy útválasztó. Hagyományos IP-al- 
hálózatok kialakításakor ugyanis óhatatlanul IP-cím pazarlás 
történik amiatt, hogy csak felezéses módszerrel lehet egy IP- 
tartományból IP-címeket kiragadni. Ez ma már persze csak az 
Internetszolgáltatókat feszélyezi, hisz belső, vállalati hálóza- 
tainkon , korlátlan" mennyiségű IP-cím áll rendelkezésünkre, 
elég, ha csak a 172.16.x.y címtartományra gondolunk. 

A hídkapcsolat tehát olyan környezetben vethető be nagy si- 
kerrel, ahol nincs kedvünk az alhálózatok IP-cím problémáival 
vacakolni. 


Internet Connection Sharing 


Az Internetkapcsolat megosztásáról korábban már szóltunk, 
így most csak felelevenítem: az ICS egy pici Network Address 
Translator (NAT), amely a belső IP-címeket külső, publikus cí- 
mekké fordítja, és viszont. Mivel az ICS-gépnek kell lennie az 
alapértelmezett átjárónak, sajnos az APIPA-címeket fel kell vál- 
tani olyanokkal, amelyekben ki van töltve ez az információ is. 
Ha kisvállalati-otthoni hálózatunkat például egy ADSL-vona- 
lon keresztül szeretnénk kiereszteni a netre, osszuk meg a kap- 
csolatot! 

Ahhoz, hogy a kapcsolatmegosztás akkor is működjön, ha a 
gépen épp senki sincs bejelentkezve, először is mentsük el a 
tárcsázás jelszavát mindenki számára: 


Csatlakozás a következőhöz: NetAcademia 


(be 


Felhasználónév: [Mace] 





Jelszó: e 





[V]4 felhasználónév és jelszó mentése a következő 
felhasználók számára: 


O Csak én 


60) Bárki, aki ezt a számítógépet használja 
1234567 vi 





Tárcsázás: 








EJ A tárcsázási név és jelszó elmentése a távoli felhaszná- 
lók zavartalan munkája érdekében történik 


Ezután jöhet a kapcsolat megosztása. Új fejlemény a Windows 
XP-ben, hogy már nem figyelmeztet arra, hogy 


TA új, statikus IP-címet rendel a belső kártyához 
(192.168.0.1) 

A elkezd IP-címeket osztani a 192.168.0.0 tartományból 
(DHCP Allocator); az összes IP-paraméterrel önmagára 
mutat, mert 

HA DNS- és WINS-proxyt telepít 

Ez kisebbfajta égszakadás-földindulással jár, de daddy úgysem 
képes felfogni az üzenet értelmét, a felhasználói tesztek szerint 
úgyis ,Yes"-t kattint, akkor meg minek borzoljuk az idegeit? 
Eddig sem tudta, mitől működik a hálózat, és az sem fáj majd 
neki, hogy APIPA helyett más IP-címek lesznek. Mindez csend- 
ben, a háttérben megtörténik és punktum. 

A megosztott kapcsolat felvázolt működése miatt igen fontos a 
hídkapcsolat lehetősége. Ha nem akarunk DHCP Proxyt telepí- 
teni a második hálózatra (az emelet subnetje), fontos, hogy az 
imént települt DHCP Allocator képes legyen IP-címet adni az 
emeleti gépekre is, ehhez pedig nem router, hanem híd kell! 


Tűzfal 


Hihetetlen dolgot mondok: az XP beépített tűzfala nem növeli 
meg a megosztott Internetkapcsolat biztonságát. Hangsúlyo- 
zom: a megosztott kapcsolatét. Ennek az az oka, hogy a kap- 
csolatmegosztás (NAT) és a tűzfal egy és ugyanazon techno- 
lógián, a belülről kért kapcsolatok megjegyzésén alapulnak, és 
csak olyan kérést engednek be, amit belülről kértünk. 

Az IP-cím-fordítás (NAT) miatt tehát sohasem jut be a belső há- 
lózatba olyan csomag, amit nem belülről kértek. Ezzel a tulaj- 
donságával a kapcsolatmegosztás magától ,hozza" az XP-be 
beépített tűzfalszolgáltatás képességeit, így ez utóbbi telepíté- 
se nem jár a védelem további növelésével. 


ra zarnab 


Ha egy önálló gépen az Internetkapcsolatot nem osztjuk 


nem indul be a portfigyelés sem! Ilyenkor igenis 





kapcsoljuk be a falat! 


Mielőtt még mindenki nekiesik saját gépén a tűzfal engedélye- 
zésének, hadd jegyezzem meg, hogy belső (LAN) hálózaton 
nem a tűzfal a védelem helyes módja, hanem a jogosultsági 
rendszer megfelelő beállítása. Ha valaki a lokális hálózati kap- 
csolaton engedélyezi a tűzfalat, azt kapja, amit a tűzfal nyújta- 
ni tud: kéretlen külső kapcsolatokat többé nem fog elfogadni a 
gépe. Megvakulnak a megosztott könyvtárak és nyomtatók, s 
az Outlookot sem fogja tudni értesíteni az Exchange Server az 
új levelekről — habár maga a levelezés megy. A LAN-kapcsolat 
tűzfalas védelme nem tilos, de csak a tűzfal mélyebb ismereté- 
ben vágjunk bele! 

A legokosabb mégis, ha az ,Internetkapcsolat tűzfala" szolgál- 
tatást a nevében megbújó célra használjuk, és csak az Internet- 
re néző közvetlen kapcsolatokon engedélyezzük, a kapcsolat 
tulajdonságlapjának Speciális fülén: 


"- NetAcademia - tulajdonságok 








( általános ]( Beállítások ]( Biztonság ( Hálózat Speciális ] 





Internetkapcsolat tűzfala 





További információk az internetes tűzfalakról, 


E Tűzfal engedélyezése egy tárcsázós kapcsolaton 


Az engedélyezést követően kéretlen kapcsolatot többé nem fo- 
gad el a gépünk, de igényelhetjük, hogy a jelenségről naplóbe- 
jegyzés készüljön. 

További érdekes lehetőség, hogy bizonyos belső szolgáltatáso- 
kat mégiscsak engedélyezhetünk. Az imént látott Speciális lap 
alján lévő Beállítások gombra megjelenő párbeszédpanel Szol- 
gáltatások fülén néhány konyhakész publikációs szabályt lát- 
hatunk. Ezek közül például a Távoli asztal nevűt kell enge- 
délyeznünk az XP Terminal Services használatához. A szabá- 
lyok engedélyezésekor megtekinthetjük, hogy az egyes szol- 
gáltatások melyik (TCP vagy UDP) porton futnak (a TS például 
a 3389-esen). 


Fa 





TŰ Bejővő vetudis magánhálózati kapcsolat ILZTP] 
JEL övék tösátseskete TŰ 
fajpráttogyatensnerer e szrgaátáááád EZTET EE 
ei erpzssáotő 

(DJ MAP3 piotokol (lntemet Mad ccers Protocol Version 3) 
) EJ apa praiokot fintermet Mai Access Piotocol Version 4) 
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A szolgákatás külső portszáma 
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A Távoli Asztal-szolgáltatás engedélyezése a tűzfalon 


A lista nem tartalmazza a Windowsos fájl- és nyomtató- 
megosztást, így ha valaki a tűzfal dacára meg szeretné osztani 
könyvtárait, vegye fel az alábbi szabályt a Hozzáadás gomb 
megnyomásával: 


Szolgáltatás beállításai 


A szolgáltatás leírása: 





Common Intemet File System 





Annak a számítógépnek a neve vagy IP-címe (pl.: 
192.168.0.12), amelyen a szolgáltatás fut: 


brokkoli 











4 szolgáltatás külső portszáma: 
445 

A szolgáltatás belső portszáma: 

449 








OIECP  OUDP 








E CIFS (Windows-megosztás) engedélyezése a tűzfalon 


Talán némi magyarázatra szorul ez a 445-ös portos varázslat. 
A Windows (NT4-ig bezárólag) NetbBIOS-réteg felett futtatja sa- 
ját Workstation és Server szolgáltatását, melyek a fájl- és nyom- 


tatómegosztás komponensei (Server Message Block 
protokoll). Az SMB használatához a 135-139 tarto- 
mányba eső TCP-portokat használjuk vegyes üzem- 
módban. Egy marék portot ki kell nyitni a használa- 
tához, ezzel ráadásul további, a tűzfalgazda számára 
ismeretlen szolgáltatások is ,kiszabadulnak". Így vált a Win- 
dowsos megosztás minden tűzfalgazda rémálmává. De ennek 
2000 óta vége lehetne. Ekkor döntött úgy a Microsoft, hogy fel- 
hagy a NetBIOS erőltetésével, és valamilyen szabványos csa- 
tornába önti az SMB hálózati forgalmat is. Windows 2000 óta 
a NetbBIOS-réteg helyett a 445-ös porton is elérhetjük mind a 
Server, mind a Workstation szolgáltatást. Sőt! Az XP először ez- 
zel próbálkozik, és csak sikertelen kísérletezés után tér vissza 
a NetbBIOS-os módszerre (kompatibilitási okokból). 


- 


Ha szabvány, akkor IETF! A Microsoft — Common Internet File 
System néven -— szabványosításra benyújtotta az IETF-hez az 
SMB-protokollt (és forráskódját). Aki nem hiszi, látogasson el a 
[3] címre! Ez a draft egy új URL-típust javasol, az smb:// kez- 
detűt. Majd meglátjuk, mit hoz a jövő, mindenesetre ez a draft 
a cikk írásának pillanatában még él, de mire kijövünk a nyom- 
dából, lejár (2003. január 8-án). Mi lesz veled, Microsoft? 


Kapcsolatmegosztás -t tűzfal 


Paradox módon az XP-tűzfalat akkor kell a NAT-gépre telepíte- 
ni, ha további szolgáltatásokat akarunk engedélyezni. Ennek 
csupán az az oka, hogy az Internet Connection Sharing para- 
méterezhetősége korlátozott. Az XP-tűzfal viszont — mint láttuk 
- lehetővé teszi, hogy bizonyos belső számítógépeken futó 
szolgáltatásokat engedélyezzünk. Ehhez a fent bemutatott 
szolgáltatásengedélyezési ablakban a szolgáltatást nyújtó gép 
nevét kell megadni a tűzfalgép neve helyett, és kész vagyunk. 


Fóti Marcell 

marcellfőonetacademia.net 

A szerző a NetAcademia vezető oktatója, a tech.net magazin 
főszerkesztője, MCSE, MCDBA, MCT 


A cikkben szereplő URL-ek: 


(11 Zeroconf Reguirements 
http://www.ietf.org/proceedings/O0dec/I-D/draft-ietfzeroconf-regts-06.txt 

[2] Dynamic Configuration of IPv4 link-local addresses 
http:/Avww.ietf.org/proceedings/OOdec/I-D/draft-ietf-zeroconf-ipv4-linklocal-01 txt 

[3] Common Internet File System ú 
http://www.ietf.org/internet-drafts/draft-erhertel-smb-url-03 txt 


Kapcsolódó tanfolyamaink: 
Windows XP nagyvállalati környezetben dí 
TCP/IP a szabványok tükrében 
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A [Microsoít operációs rerd- 
szerek biztonsági tényezői 


I. rész — Hová építsünk palotát? 
Ingoványra vagy kősziklára? 


Cikksorozatomban végigvezetem a Kedves Olvasót azon a hosszú úton, amit a Microsoft megtett, mi- 
re — néha saját korábbi technológiáival is leszámolva — elérkezett arra a pontra, hogy fejlesztéseinek 
célja a világ legbiztonságosabb operációs rendszerének megalkotása legyen. A cég rögös, és tévedé- 
sektől sem mentes, mindazonáltal világosan felismerhető utat követ. Lássuk, merre jár Bill és csapata! 


Ha egy laikus, de PC-t használó ismerősünket megkérdez- 
nénk, hogy szerinte mennyire biztonságosak a Microsoft által 
gyártott operációs rendszerek, akkor szinte biztosak lehetünk 
benne, hogy azt válaszolná: egyáltalán nem. Azután sorolná 
azokat a félig megértett híreket, amelyekkel a média bombáz- 
za az Internet veszélyeitől amúgy is megrettenő számítógép- 
felhasználókat. 

Ha van stigma, amelyet nehezen mos le magáról az amerikai 
szoftveróriás, az a szoftvereinek megbízhatatlansága. Pedig 
nem akármilyen erőfeszítéseket tett a cég, hogy ettől a kétes 
hírnévtől megszabaduljon! Ám a mindig jól működő marke- 
tinggépezet ezúttal nem sokat segít. A monolit Microsoft rend- 
szerek, amelyeket szerver- és ügyfél operációs rendszerek, 
szerver-alkalmazások, Internet-böngésző, levelező programok 
és irodai programcsomagok alkotnak, a felhasználók számára 
va" rendszert jelentik, s ha bármely részében biztonsági hibát 
találnak, az ,egész rendszer" találtatik könnyűnek. 

Az alábbiakban — némi történelmi áttekintés után — azt veszem 
górcső alá, hogy milyen biztonsági technológiákat és eljáráso- 
kat épített a Microsoft az operációs rendszereibe, és milyen 
szolgáltatásokat nyújt, hogy a vállalati és otthoni felhasználók 
biztonságban érezhessék magukat. 


A Microsoft operációs rendszerek evolúciója 
Indulás: PC és MS-DOS 


A Microsoft bábáskodott a PC megszületésekor: jókor volt a 
megfelelő helyen. Az IBM terméke, és a mögötte lévő straté- 
gia fényes sikert aratott (meglepve még a nagy kék céget is), és 
robbanásszerűen terjedt el előbb az Egyesült Államokban, 
majd a világ többi részén. A PC azonban nem jelentett mást, 
mint egyedi, személyi számítógépet hálózati kapcsolat és bi- 
zalmas, értékes adatok nélkül. Ahol pedig nincs mit védeni, 
ott nincs szükség biztonsági intézkedésre sem. A külsőleg 
Unix stílusú MS-DOS-ból tehát hiányzott minden, ami a biz- 
tonsággal kapcsolatos. Sem a jogosultságkezelés, sem a fel- 
használói azonosítás nem volt a rendszer része. Mi több, ma- 
ga az Intel architektúra is csak a 286-os processzoroktól kezd- 
ve tette lehetővé, hogy a rendszerszoítverek eltérő üzemmód- 
ban fussanak (valós és védett üzemmód). Az MS-DOS nem ju- 
tott el ilyen magasságokba. A 6.22-es változattal úgy vonult 


nyugdíjba, hogy komoly üzleti alkalmazások biztonsági igé- 
nyeit sohasem támogatta. 

A problémák is ebben az időben keletkeztek. Egy kutató fel- 
hívta a figyelmet, hogy lehetséges olyan programkód megal- 
kotása, amely képes önmaga reprodukálására — ezeket a prog- 
ramkódokat vírusoknak nevezték el. Az első mókás — és sok 
kárt nem okozó — példányok után megjelentek a valódi ve- 
szélyt jelentő egyedek, — a célrendszer pedig két ok miatt is a 
Microsoft DOS (később Windows) rendszere lett: egyrészt hí- 
jával volt mindenféle biztonsági alrendszernek, ugyanakkor 
valamennyi számítógéparchitektúra közül a legelterjedtebb- 
nek számított. Végül az instabilitás, a gyenge rendszer-archi- 
tektúra, és nem utolsó sorban a vírusok elterjedése meghozta 
a kétes gyümölcsöt: a Microsoft rendszerei megkapták a 
,Megbízhatatlan" jelzőt. Csak a tisztesség kedvéért jegyezzük 
meg, hogy a szoftvercég az MS-DOS 6.2-től még (licencelt) 
antivírus szoftvert is árult az alaprendszerhez, ám elfelejtette 
biztosítani a mindenkori legfrissebb vírus-adatbázist, ezért a 
megoldás hamvába holt. 

A történeti áttekintéshez fontos adalék, hogy a Microsoft és az 
IBM egymásra találtak, és — felismerve a DOS fogyatékossága- 
it — egy új, korszerűbb operációs rendszer kifejlesztésébe kezd- 
tek. A Microsoft folyamatosan átvette az IBM által fejlesztett 
technológiákat, többek között a hálózati protokollokat és szoft- 
vereket is. Ezek közül külön említést érdemel a NetBIOS és a 
hozzá kötődő szabványcsalád. A közös gyermek, az OS/2 
megszületett ugyan, sőt a mai napig létezik, de mindkét szülő 
magára hagyta: a Microsoft a Windows irányába távozott, az 
IBM pedig sohasem tekintette stratégiai termékének. 


A Windows 3.1-től a Millennium Editionig 


A grafikus képernyők, kártyák és az ablakozó technológia meg- 
mozgatta a Microsoft mérnökeinek (no meg üzleti stratégáinak) 
fantáziáját, és sorra jelentek meg a Windows változataival. A 
Windows 3.1 hatalmas lökést adott a PC iparnak. Rút kiskacsa 
ez a mai rendszerekhez képest, de akkor mindenki ezt akarta: 
grafikus felület, könnyű kezelhetőség. Ebben az időben érke- 
Zett meg a helyi hálózat a szélesebb tömegekhez, a vállalatok- 
hoz és közintézményekhez. A hálózati operációs rendszerek 
királya koronázatlanul is a Novell cég Netware szoftvere volt. 
Virágkorában a piaci részesedése meghaladta a 9099-ot. A Mic- 
rosoft ellátta a Windows rendszereit hálózati csatlakozási lehe- 


tőséggel (akár Netware szerverekhez is), majd az IBM-től ka- 
pott alapokkal elkezdte favorizálni a maga megoldásait. Talán 
ettől az időtől volt jellemző a cégre, hogy az általános tenden- 
ciák, vagyis a de facto szabványok helyett a saját fejlesztéseit 
igyekezett a rendszerüzemeltetőkre erőltetni. Így történt, hogy 
minden Windows termék a NetBIOS szabványt (NetBEUI, 
WINS, Browsing stb.) támogatta, háttérbe szorítva a Novell 
IPX/SPX technológiáját. 


A biztonsági szempontból látszólag érdektelen szabványcsata 
mögött nagyon is valóságos biztonsági problémák kezdtek ki- 
rajzolódni. A hálózatok növekedésével nemcsak a NetBIOS 
méretezési problémái kerültek előtérbe, hanem a szabványba 
rejtett tervezési gondok is, mint például a csomagszórás, a hi- 
telesítés hiánya több hálózati elemi szolgáltatásnál (WINS), 
útvonalválasztási képességek stb. A hálózati front mellett 
az alaprendszer megbízhatósága továbbra is kétes maradt. 
Az evolúciós fejlődés (biztonsági szempontból) zsákutcába" 
terelte a hajdani garázscéget. A termék megszületésekor ott- 
honi felhasználóknak csupán egy felület készült, mindenféle 
biztonsági igény nélkül, ám nemsokára vállalatok tértek át az 
új platformra (a PC-re, s vele együtt a Windowsra), amely egy- 
re fontosabb üzleti adatokat és titkokat őrzött a gyakorlatilag 
védtelen PC-k merevlemezén. Az ellentmondást nem lehetett 
feloldani. Bár néhány kísérlet született (az is főleg külső gyár- 
tótól), a Windows termékcsalád ezen vonala -— a kezdeti hiá- 
nyosságok megmaradása miatt — nem tekinthető megbízha- 
tónak és biztonságosnak. A legfontosabb hiányosságok az 
alábbiak: 


IA Nincs felhasználóazonosítás vagy az egyszerűen meg- 
kerülhető. 

Nincs jogosultság- és engedélykezelés. 

Nincs címtár. 

A felhasználó a saját rendszerében bármit megtehet. 
A vírusok továbbra is korlátlan lehetőségekkel rendel- 
keznek. 

HA Nincs biztonságos állományrendszer. 


8868 


A Windows 98-tól néhány biztonsági alkotóelem a rendszer 
részévé vált. Ilyen volt például a személyi tűzfal vagy rendszer- 
visszaállítási pont a Millennium Editionben, ám a komponen- 
sek csak korlátozott funkcionalitással rendelkeztek, és semmi- 
képp sem alkottak összefüggő egészet. Az egyetlen terület, 
ahol a Microsoft nagy erőfeszítéseket tett, az a betárcsázás. A 
Windows 3.1-től elérhetőek voltak, és a termékvonallal együtt 
mind jobb és jobb megoldások, titkosítási algoritmusok épültek 
be a telefonos alrendszerbe. Ennek elsősorban az volt az oka, 
hogy a hordozható számítógépek sokáig csak a Win9x termék- 
vonal különféle verzióit futtatták. A nagyobb testvér, az NT, 
nem támogatta kellően a notebookokat. 

Feltehetnénk a kérdést: miért nem építettek komoly biztonsá- 
gi rendszert a Windowsba? Mielőtt válaszolnánk, tegyük a szí- 
vünket a kezünkre: vajon a sokat dicsőített Internet, melynek 
technológiája korábbi, tehát érettebb is, mint a szoftveróriás 
megoldása, vajon biztonságos? A telnet, az ftp, a http, a Unix 
1990-es évek elején használt jelszótárolása kifogástalan volt? 
A válasz az, hogy nem. A világ változik. Ami 15 évvel ezelőtt 
megfelelő volt, ma már nem az. Ami pedig a Microsoftot és a 
felhasználók ,cserbenhagyását" illeti, azt mondhatjuk, hogy a 
cég valójában nem hagyta cserben a vásárlókat, ezen belül a 
biztonsági funkciókat erősen hiányoló vállalati ügyfeleket, 
csak a várt eljáráshoz képest egy másikat választott. 


A Windows NT család 


1984-85 táján egyértelművé vált a Microsoft emble- 
matikus figurája, Bill Gates és stratégiai tanácsadói 
előtt, hogy a céget a vállalati piac teheti naggyá. Ám 
az is világossá vált, hogy a viszonylag kicsi szoftver- 
gyártó még nem képes egy — a vállalati igényeket minden 
szempontból kielégítő — operációs rendszer megalkotására. Az 
is érthető volt a stratégák számára, hogy csak egy önálló ter- 
mékkel őrizhető meg a cég függetlensége. 
Mindezeket mérlegelve az a döntés született, hogy a Microsoft 
a vállalati erőforrásokat megosztva három rendszert fejleszt 
egyszerre. Tovább folytatódott az OS/2-es összeölelkezés az 
IBM-mel, elsajátítva ezáltal a szükséges vállalati fejlesztői- és 
projektképességeket. Haladt a maga útján az MS-DOS, amely 
az akkor még csak 2.11-es verziószámmal rendelkező Win- 
dows-zal együtt a forrásokat biztosította. Végezetül a Digital 
vállalatóriás megsértődött szoftverfő- 
mérnökét (David Cutlert) elcsábítva 
megkezdődött egy teljesen új alapo- 


A hálózatok növeke- kon álló, a biztonsági szempontokat 
messzemenően figyelembe vevő új 
désével nemcsak operációs rendszer család kifejleszté- 
se. A rendszert nemes egyszerűséggel 
a IetBIOS méretezési . New Technology, röviden NT néven 
emlegették, és 1993-ra készült el az 
problémái kerültek első kereskedelmi forgalomba hozha- 


tó változat (Windows NT 3.1). 
Egyesek szerint az NT rövidítés nem 
teljesen véletlen. Ha hozzávesszük a 


előtérbe, hanem 


a szabványba rejtett windows előtagot is, VWVNT-hez ju- 
ho ú tunk. Ha most mindhárom betűt fel- 
tervezési gondokis. cseréljük az ABC-ben előtte álló ka- 


rakterrel, a VMS betűhármashoz ju- 

tunk. Az elcsábított Digitalos fejlesztő- 
mérnök, David Cutler a VMS és a WNT atyja. A két operációs 
rendszer memóriakezelése, ütemezése, prioritási szintjei nem 
egyszerűen hasonlóak, hanem azonosak! A rendszer architek- 
túrájának biztonságához kétség sem fér. Ha bármi kívánnivalót 
hagyott maga után a múltban, az a megvalósítás volt. 
A számítások minden szempontból beváltak. A megszerzett ké- 
pességek után el lehetett hagyni az IBM-mel közös hajót, ezzel 
az OS/2-t is. A fejőstehén szerepét játszó MS-DOS mellett fé- 
nyes csillagként hozta a hasznot a Windows 3.0, majd 3.1 és 
a 3.11, hogy azután a pénzeket elnyelje a nagy kérdőjel (a ne- 
héz gyerek) NT, amely a sikerre való tekintettel , Windows" ne- 
vet és külsőt kapott. 
A sikernek azonban ára volt. A rendszer ugyan biztonságos lett, 
ámde nagy, lomha, bonyolult és erőforráséhes. (Volt, aki úgy 
oldotta fel a rövidítést, hogy ,Not Today", vagyis ,nem ma", 
amivel egyszerre utalt a reményteli jövőre és a jelenlegi gyá- 
szos teljesítményre.) Az NT tele volt fejlesztői hibákkal, és 
ugyanazokkal a gyermekbetegségekkel küzdött, mint amivel 
minden induló operációs rendszer: nem volt kellő mennyiségű 
eszközkezelő, amely a hardver-elemeket támogatta volna, nem 
volt minden tekintetben kompatibilis-a korábbi Windows alkal- 
mazásokkal (többek közt a teljes egészében 32-bites architek- 
túra miatt), és nem voltak saját alkalmazásai. Egy új evolúciós 
vonal keletkezett, amely két kérdést vetett fel: sikeres lesz-e az 
új termék, s ha igen, akkor mi lesz a Windows korábbi verzió- 
jával. Az első kérdés megválaszolására csupán négy, a máso- 
dikra nyolc évet kellett várni. 
A Windows NT 4.0 nagy, a Windows 2000 pedig bombasikert 
aratott, az egekbe repítve a cég részvényeit. A korábbi Win9x 
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vonal 2001 őszén beolvadt az NT legújabb, Win- 
dows XP-nek nevezett, 5.1-es belső verziószámmal 
rendelkező termékébe. 


A Windows 2000 biztonsági funkciói 


A rövid történelmi kitekintés után megvizsgáljuk, milyen tulaj- 
donságokkal rendelkezik a Windows 2000 (belső verziószáma 
NT 5.0) és a Windows XP (NT 5.1). Először áttekintjük az ope- 
rációs rendszer architektúráját és a tervezéskor az alaprend- 
szerbe illesztett biztonsági tényezőket. Ezután a vállalati cím- 
tárat vesszük szemügyre, és igyekszünk rávilágítani a címtár lé- 
téből és tulajdonságaiból fakadó lehetőségekre, amelyekkel a 
rendszerünk biztonságát növelhetjük. Röviden ismertetjük a 
Windows 2000 hitelesítési rendszerét és a hozzá kapcsolódó 
szabványokat. Ezt a nyilvános kulcsos architektúra áttekintése 
követi. Górcső alá vesszük a naplózási funkciókat, amelyek a 
biztonsági rendszert érintik, majd kitérünk a hálózati biztonsá- 
got elősegítő technológiákra és az alkalmazott titkosítási algo- 
ritmusokra. Megvizsgáljuk, hogy az alaprendszerhez adott al- 
kalmazások milyen biztonsági lehetőségeket tartalmaznak, vé- 
gezetül néhány gyenge pontra hívjuk fel a figyelmet. 

A rendelkezésre álló terjedelem nem teszi lehetővé, hogy az 
egyes funkciókat részletesen vizsgáljuk, de ha az implementá- 
ció során a fejlesztők tervezési hibát vétettek, és az ismert, ak- 
kor azt mindenképpen megemlítjük. A Windows 2000-et több 
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mint 4 évig készítették (nem beszélve a megelőző 7 év tapasz- 
talatairól), ezért túl sok elvi hiba nem került a termékbe. 


Az operációs rendszer architektúrája biztonsági szemszögből 


A Windows 2000 legfontosabb alkotóeleme — akárcsak más 
operációs rendszereknél - a kernel tulajdonképpen a rendszer 
szíve. 

A kernel különböző komponensei felelősek azért, hogy ki (mi) 
mikor, milyen mértékben és meddig használhat egy hardver 
vagy szoftver erőforrást. A kernel biztonságos módon elválaszt- 
ja egymástól az alkalmazásokat, és nem engedi, hogy bármely 
program oly mértékben kisajátítson magának egy erőforrást, 
amely már a rendszer működésének egészét veszélyezteti. Egy 
Windows 2000 rendszerben a kernel az , úr" és senki más. A 
tervezésnek köszönhetően egy alkalmazás összeomlása nem 
befolyásolja a többi működését, — ez merőben más, mint a 
Win3.x és Win9x rendszerek részben vagy egészben koopera- 
tív multitaszk üzemmódja, ahol bizony egyetlen rosszul meg- 
írt alkalmazás a sírba vitte a többit is. 





A kernel gondoskodik arról is, hogy az egyes futó programok- 
hoz privilégiumszinteket rendeljen. A privilégiumszint lehet 
kernel mód, ami lényegében a teljes szabadságot jelenti a 
hardvererőforrások felett, és lehet user mód, amely lényegesen 
korlátozottabb lehetőségeket nyújt. Kernel üzemmódban olyan 
rendszerkomponensek futhatnak, mint a memóriamenedzser, 
az I/O menedzser, a file-rendszer menedzser stb. Minden más 
user üzemmódban indul. Ez a megoldás (amely egyébként 
más, nagyvállalati operációs rendszereknél, többek között a 
Unixoknál is általános) alapvetően hozzájárult a vírusok bizo- 
nyos típusainak teljes eltűnéséhez. 
Szabály ugyanis, hogy egy alkalmazás 
örökli az őt indító objektum privilégi- 
umszintjét. Ez azt jelenti, hogy az egy- 
szerű, korlátozott jogokkal rendelkező 
felhasználók által (nem szándékoltan) 
indított vírusok szintén csupán korlá- 


A Windows 2000 
2002. október 29-én 


megkapta a Common . tozott jogokkal indulnak, így a rend- 
ZEN szer főbb komponenseiben nem te- 

Criteria ERLG hetnek kárt. 

szintű minősítést. A Windows 2000 sajátossága, hogy a 


szakemberek biztonsági elvárásait 

szem előtt tartva biztonsági egyedek- 
ben (security principals) gondolkodik. Biztonsági egyed min- 
den olyan objektum, amely valamilyen cselekvést kezdemé- 
nyez. Így megkülönböztethetünk felhasználókat, csoportokat, 
számítógépeket, tartományokat, amelyekhez jogokat (rights) és 
jogosultságokat (permissions) rendelhetünk, ha kell egyszerű- 
en, de szükség szerint akár rendkívül cizellált módon is. Min- 
den objektumnak tulajdonosa is van, amelyet a rendszer szá- 
mon tart. 
Az architektúra igen jól sikerült, mert a Windows 2000 egy 
majdnem két évig tartó folyamat eredményeképpen 2002. ok- 
tóber 29-én megkapta a Common Criteria EAL4 szintű minősí- 
tést. Ez nagyjából a régi ITSEC C2-nek megfelelő biztonsági 
szint; ennél magasabbat nem kaphat szokásos kereskedelmi 
forgalomban kapható operációs rendszer. 
A rendszer másik fontos alapköve a programok, alkalmazások 
és adatok tárolását megvalósítani hivatott fájlrendszer. Ezt 
NTFS-nek hívják már 1993 óta, és sokféle módon szolgálja a 
biztonsági igényeket. A tárolt adatokhoz és állományokhoz 
úgynevezett hozzáférés vezérlési listákat (Access Control List 
vagy ACL) rendelhetünk. 
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] A különleges engedélyekkel kapcsolatos további információt úgy tudja megtekinteni, hogy az alábbi 
listában kijelöl egy engedélyt, majd rákattint a Szerkesztés gombra. 
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Az örökölt engedélyek alkalmazása. Az ezen a párbeszédpanelen megadolt engedélyek mellett az 

örökölt engedélyek is érvényesek lesznek. 

[DA gyermekobiektumokra érvényes (örökölhető) engedélyek lecserélése az üt megadott, 
gyermekobjektumokra érvényes engedélyekre. 
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Jogosultság beállítása egyszerűen, összetett módon 
vagy aprólékosan — igény szerint 


Ez a lista tartalmazza azt, hogy ki férhet hozzá egy állomány- 
hoz, és amennyiben hozzáférhet, akkor mit tehet azzal (olvas- 
hatja, módosíthatja, törölheti stb.). Egy könyvtárra vagy állo- 
mányra vonatkozóan 13 különböző műveletet definiáltak a 
programozók. Egy-egy műveletet műveletcsokorba lehet szed- 
ni, például az ,olvasás" jog azt jelenti, hogy a felhasználó 
láthatja a mappát és listázhatja azt, attribútumokat, kiterjesz- 
tett attribútumokat és engedélyeket olvashat". A Windows 
2000-hez tartozó NTFS változat számos új szolgáltatással bő- 
vült, ezek a következők: 


A Titkosítás: a nyilvános kulcsos infrastruktúrával integ- 
rálható, de önállóan is használható eljárás. A rendszer 
beépített visszaállítási módszert is tartalmaz, amely a 
jelszó illetve kulcs elvesztése esetén (csak bizonyos 
esetekben) képes az adatok visszaállítására. A felhasz- 
náló számára a felület rendkívül egyszerű. Csupán egy 
jelölőnégyzetben kell beállítani, hogy az adatokat tit- 
kosítani szeretnénk. Ettől kezdve az állományok táro- 
lása megváltozik, a rendszer pedig megnyitáskor és 
bezáráskor (a kulcs megléte esetén) automatikusan el- 
végzi a visszafejtést és a titkosítást. 

TA A jogosultságok öröklődése. Az elv rendkívül egysze- 
rű: a mappahierarchia egy felső szintjén beállított ACL 
lecsorog" az alsó szintekre, így könnyebben szabá- 
lyozható nagyobb könyvtárstruktúrák hozzáférési 
rendszere is. Az öröklődés megállítható és újraindítha- 
tó. A Microsoft a módszert minden olyan fejlesztésébe 
átvezette, amelyben hierarchia és hozzáférés-szabá- 
lyozás létezik, ezért megtalálható a címtár és a regiszt- 
rációs adatbázis jogosultságrendszerében is. 

AA Az állományrendszer nemcsak az engedélyek tárolá- 
sával szolgálja a biztonságot, hanem önmaga stabilitá- 
sával is, hiszen ő hordozza a teljes működő szoftvert. 
Az NTES tranzakcióalapú fájlrendszer, amely azt je- 
lenti, hogy az adatok kiírása a lemezre két fázisban 
történik. Először egy tranzakciónaplóba kerülnek az 
állományok, majd innen a tényleges helyükre. A mód- 
szer biztosítja, hogy a fájlrendszer mindig konzisztens 
állapotban maradhasson. Ezt az elvet az adatbáziske- 
zelő rendszerek használták először. A sok hasonlóság 
miatt hosszú távon várható, hogy a Microsoft össze- 





vonja állományrendszerének és SOL termé- 
kének fejlesztését. 

A A stabilitást szolgálja a naplózás (journaling) 
is. Az eljárás azt jelenti, hogy egy belső állo- 
mányban az NTEFS tárolja, hogy milyen adat 
mikor és milyen objektum által változott meg. Az ada- 
tok felhasználásával például nagyságrendekkel gyor- 
sabb víruskereső programokat lehet készíteni, amelyek 
mindig csak a változásokat vizsgálják. 


Az alaprendszer ismertetésekor érdemes megjegyezni, hogy a 
Microsoft szakított a korábbi változatok mindent megengedő 
alapbeállításával, és már az induló, frissen telepített Windows 
2000 is határozott korlátozásokat érvényesít az alacsonyabb 
hozzáférési szinteken elhelyezkedők számára. Elsősorban a 
gyökér, a WINNT és a SYSTEM32 könyvtárakat védi a rend- 
szer, szabályozva az állományok elhelyezésének módját. 
Ezen kívül szigorúbbak a beállítások a regisztrációs adatbázis- 
ban is. Unix-környezetben ez megszokott volt, a Windowst 
használók azonban meglepődtek, de hamar belátták a változ- 
tatás szükségességét. 
A működés stabilitását és az összeomlások megakadályozását 
szolgálja az új , Windows File Protection" (WFP) szolgáltatás. 
Ennek lényege, hogy a legfontosabb programokról és eljárás- 
könyvtár-állományokról (dII-ekről), azok méretéről, verziószá- 
máról pontos nyilvántartást vezet a 
rendszer. Amennyiben egy alkalma- 
zás a védett állományokat korábbi, 


A Microsoft szakított vagy más nyelvű verzióval felül sze- 
retné írni, a WFP ezt megakadályoz- 
a korábbi változatok za: egy rejtett könyvtárból visszamá- 
solja a védett állományt. 
mindent megengedő A Microsoft nevével összefonódott a 
híres hármas billentyű-kombináció a 
alapbeállításával, CTRL-ALT-DEL. A DOS világában ez 
egy újraindítást jelentett, a Win9x 
és már az induló, rendszerekben a billentyűkulcs elő- 
ször csak egy feladatkezelőt indított. 
írissen telepített A Windows NT-ben és a Windows 
2000-ben ezzel a hármas leütéssel in- 
Windows 2000 is ha- dítjuk el a bejelentkezést. Kevesen 
tudják, hogy komoly szándékok hú- 
tározott korlátozá- zódnak meg a kikényszerített eljárás 
mögött. A felhasználónak ebben a 
sokat érvényesít. fázisban kell megadnia a jelszavát. 


Az azonosítás megkerülhetetlensége 

mellett fontos, hogy a jelszót ne egy 
trójai faló" nyelje el, hanem biztosak lehessünk abban, hogy 
csak az operációs rendszernek adjuk át. A fenti billentyűzet- 
kombináció minden futó alkalmazástól elveszi a vezérlést, és 
a Winlogon processznek adja azt, ezáltal szűrve az esetleges 
jelszólopó programokat. A hitelesítő alrendszer egyébként 
moduláris, a beléptetési módszer lecserélhető. A jelszómeg- 
adás helyett tehát — megfelelő megoldás megvásárlásával — 
használhatunk intelligens kártyás vagy biometrikus azonosí- 
tást is. A nyilvános kulcsú architektúra mindig ott van a háttér- 
ben, mint egy lehetséges kiegészítője a fenti technológiáknak. 
Ez pedig nemcsak a hitelesítésre igaz. A Windows 2000 esz- 
közkezelői például digitálisan aláírhatók, a rendszergazdák 
szabályozhatják, hogy mit tegyenek az alá nem írt eszközke- 
zelőkkel. A digitális aláírás arról biztosít, hogy a szoftverkom- 
ponenst a Microsoft bevizsgálta, és stabilnak minősítette, vár- 
hatóan nem fog problémát okozni a telepítése. 
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A Microsoft operációs rendszerek biztonsági tényezői 


ME 


Végezetül meg kell említenünk a regisztrációs adat- 
bázist, amely a Windows NT termékcsalád speciali- 
tása. Az eredeti elképzelés szerint a tervezők egyet- 
len, közös, hierarchikus fastruktúrába szervezett, 
konfigurációs paramétereket tartalmazó adatbázist 
szerettek volna alkotni, amely a rendszer teljes beállításhalma- 
zát tartalmazta volna. Ez a módszer lett volna hivatott a rosszul 
skálázható INI állományok leváltására, a fejlesztők és a rend- 
szergazdák körében azonban nem aratott osztatlan sikert. A fej- 
lesztőknek át kellett térni az új megoldásra, ami sok energiát 
igényelt, a rendszergazdáknak pedig meg kellett ismerniük ezt 
az eszközt, ami egyáltalán nem volt egyszerű, tekintve, hogy 
nem készült hozzá dokumentáció. Egy beállítást könnyű elhe- 
lyezni az adatbázisban, de nehéz megtalálni. Többféle adattí- 
pus létezik, és a fejlesztők kénye kedve szerint egy jelölőnégy- 
zet az adatbázisban hol egy hexadecimális szám, egy karakter, 
hol pedig egy nagyobb hexadecimális szám egyetlen bitje. 

Sok kellemetlenséget okozó tulajdonsága mellett azonban van 

néhány határozott előnye is a megoldásnak. Ezek a következők: 

1. Világosan elkülöníthetők a felhasználói- és a rendszerbeál- 
lítások. Az előbbiek a HKEY USERS, az utóbbiak a 
HKEY LOCAL MACHINE ág alatt találhatók. A felhaszná- 
lók beállításai egymáshoz képest is elválaszthatók, sőt gép- 
ről-gépre hordozhatók. (A Windows 2000 logóval rendel- 
kező szoftvereknek ismerniük kell ezeket a fogalmakat, és 
a megfelelő módon alkalmazniuk kell.) 

2. A rendszerbeállításokhoz különböző engedélyeket rendel- 
hetünk. Ezzel megakadályozhatjuk, hogy illetéktelenek 
vagy dilettánsok hibás paramétereket állítsanak be. A Win- 
dows 2000 tartalmaz is ilyen korlátozásokat, sőt a Win- 
dows XP még szigorított is ezen. Az engedélyek nemcsak 
egyénekre, hanem csoportokra is vonatkozhatnak, és mű- 
ködik a jogöröklés modellje is. Sőt, a Windows 2000 cím- 
tárát és a csoportházirendeket felhasználva akár egyetlen 
helyről akármennyi Windows 2000-es rendszerre érvényre 
juttathatunk regisztrációs adatbázis biztonsági beállításo- 
kat, — erről egy kicsit később még szólunk. 


TAT Agar g AZt 3 
Objektum 
Az engedély a szülőobjektumtól öröklődik. 


Név: (Users (MAL-O444Users) ! 


Alkalmazás: (Ezakulcsé és az alkulcsok 


Engedélyek: 
Teljes hozzáférés 
Lekérdezési érték 
Érték beállítása 
Alkulcs létrehozása 
Alkulcsok felsorolása 
Értesítés 
Csatolás létrehozása 
Törlés 
Írás DAC 
frásra jogosult tulajdonos 
Vezérlőadatok olvasása 
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Üsszes törlése 


— Az engedélyek alkalmazása a fán lejjebb 
" található objektumokra és/vagy tárolókra 





A Windows 2000 még kétféle regisztrációs adatbázis szerkesz- 
tő szoftvert tartalmaz: a regedit.exe-t és a regedt32.exe-t. Az 
előbbivel kényelmesebb keresni, de nem állíthatók vele jogo- 
sultságok, az utóbbi kicsit kényelmetlenebb felületet ad, de a 
biztonsági előírások teljesítését maradéktalanul segíti. A Win- 
dows XP-től kezdve a két alkalmazás az előnyös tulajdonságo- 
kat ötvözve egyesült. 


A vállalati címtár 


A számítógépek, akár PC-k, akár szerverek ma már szinte kivé- 
tel nélkül kapcsolódnak valamilyen technológiával egy háló- 
zathoz. A technológia lehet egy analóg telefonvonal, egy ká- 
belmodem, egy ADSL kapcsolat vagy egy Ethernet csatoló, a 
hálózat pedig lehet egy otthoni mini háló vagy vállalati LAN, 
esetleg maga az Internet. 

A Windows 2000 egyik legnagyobb újdonsága a továbbfejlesz- 
tett címtár, amelyet a Microsoft Active Directorynak nevezett 
el. A címtár elsősorban a vállalatok informatikusainak életét 
könnyíti meg. Tulajdonképpen egy speciális, elosztott, rugal- 
masan bővíthető, konfigurálható, paraméterezhető, skálázható 
adatbázisról van szó. Külön megjegyzendő, hogy az Active Di- 
rectory egy internetes szabványra, nevezetesen a DNS névfel- 
oldó szolgáltatásra támaszkodik. 


Active Directory Namespace DNS Namespace 
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dient1.reskit.com IN A 172.16.72.1 


ványokat erőltessen a felhasználókra, inkább a mindenki által 
használt, így kompatibilis Internetes szabványokat és technoló- 
giákat helyezte előtérbe. 

A címtár mint adatbázis elvileg bármilyen adatot tárolhat, mert 
a séma, amely tárolt objektumokat és azok tulajdonságait leír- 
ja, bővíthető. Leegyszerűsítve: a címtár objektumokat és azok 
tulajdonságait tárolja. Az objektum egy valóságosan létező 
valami" informatikai leképezése. Ilyen például a felhasználó. 
A címtár tartalmaz egy ,felhasználó" objektumtípust. Amikor 
szeretnénk, hogy egy munkatársunk használhassa a hálózatun- 
kat, létrehozunk egy őt reprezentáló, , felhasználó" típusú ob- 
jektumot a címtárban. Az egyes objektumoknak meghatározott 
tulajdonságai vannak. Ilyen tulajdonság lehet többek között a 
vezetéknév, a keresztnév vagy a jelszó. Az objektumtípusok 
közül a legismertebbek a felhasználó, a csoport, a számítógép, 
a hálózati mappa, a hálózati nyomtató, a csoportházirend és a 
betárcsázási házirend. Nem kell sok fantázia hozzá, hogy be- 
lássuk, igen sokféle tevékenységhez jó egy címtár. Tárolhatjuk 
az e-mail címeket, korlátozásokat léptethetünk életbe, szoft- 
verbeállításokat tarthatunk benne. 

A címtár biztonsági vonatkozásai is sokrétűek. Hasonlóan a 
szintén hierarchikus állományrendszerhez, hozzáférési listát 
tárol minden egyes objektumához, hogy a megfelelő művele- 


teket csak az arra kijelölt személyek végezhessék el. A jogo- 
sultságok öröklése itt is működik. 

Nemcsak az objektumokat védik, hanem a szoftver működését 
is. Mivel a címtár elosztott rendszer, a tagok között ki kellett 
alakítani valamilyen másolási, replikációs eljárást. Ez azt jelen- 
ti, hogy az objektumok bizony , vándorolnak" a hálózaton. Az 
informatikus szerencsére megvédheti az illetéktelen hozzáfé- 
réstől a hálózaton közlekedő adatokat, — a replikációt titkosíta- 
ni lehet, az adatfolyam digitálisan aláírható, hogy meg lehes- 
sen győződni azok sértetlenségéről. A két, egymással kommu- 
nikáló szerver pedig a Windows 2000 beépített hitelesítési 
rendszerével, a Kerberos-szal győződhet meg arról, hogy a túl- 
oldalon valóban az a szerver küldi vagy fogadja az adatokat, 
amelyiknek kell. 

Az alaprendszert úgy alakították ki, hogy bizonyos speciális 
műveleteket csak különleges jogokkal rendelkező felhasználók 
végezhetnek el (Enterprise Administrators, Schema Administra- 
tors). Ezek a felhasználók lehetnek külső szaktanácsadók is, így 
a címtár támogathatja azt az elvet, hogy bizonyos biztonsági 
funkciókat külön kell választani, — önellenőrzést nem végezhet 
senki. A fenti szerepkörök definiálásából adódik, hogy megfe- 
lelően szervezett munka esetén senki nem tüntethet el nyomo- 
kat. (Az Enterprise Administrator például magához vonhatja a 
rendszernapló törlésének jogát a tartományi rendszergazdák- 
tól.) 

Ugyancsak beépített funkció a feladatdelegálás. A címtár hie- 
rarchikus szerkezete lehetővé teszi, hogy a felelősséget és a fel- 
adatokat alacsonyabb szintre delegálhassuk. A delegált jogkö- 
rök lehetővé teszik bizonyos adminisztratív feladatok ellátását, 
de nem engedik a felsőbb szintek illetéktelen konfigurálását. A 
biztonságos vállalati hálózat egyik sarkköve, az elkülönített fel- 
adatkörök támogatása köszön vissza a szoftverben. 

Említettük már, hogy a címtár sémája bővíthető. Ez azt jelenti, 
hogy akár a Microsoft, akár más gyártók által írt alkalmazások 
újabb objektumtípusokat és objektumokat helyezhetnek el a 
központi tárolóban. Ilyen alkalmazás az Exchange 2000, 
amely levelezéssel, útvonalválasztással kapcsolatos objektu- 
mokat helyez el a tartományvezérlőkön. 

Ha egy alkalmazás , ismeri" a címtárat, tudását felhasználva az 
Active Directoryra támaszkodhat a felhasználók azonosítása- 
kor, megspórolva egy saját hitelesítési rendszer kialakítását és 
állandó karbantartását. Egy ilyen integráció következménye, 
hogy a felhasználónak kevesebb jelszót kell megjegyeznie, 
mert az alkalmazások ,tudják, kiről van szó". Ez biztonságo- 
sabb megoldás, mintha a munkatársak folyton felírnák 8-10 kü- 
lönböző jelszavukat. A címtár és az alkalmazások ilyen össze- 
növését ,egyszeri belépésnek", angolul ,single sign on" eljá- 
rásrendnek nevezik. 

Nagyon fontos eszköze a Windows 2000 alapú rendszereknek 
a biztonsági házirend. Valójában egy beépített, címtárral integ- 
rált alkalmazásról van szó. 

A biztonsági házirend lehetőséget nyújt arra, hogy valamennyi, 
a mi hatáskörünkbe tartozó számítógépre azonos biztonsági 
előírásokat alkalmazhassunk. A biztonsági előírások vonatkoz- 
hatnak a jelszókezelésre, bizonyos tevékenységek elvégzésére, 
a felhasználók jogaira, sőt, akár állományokhoz és regisztráci- 
ós kulcsokhoz rendelt engedélyeket is propagálhatunk a házi- 
rend segítségével. Mód van előre elkészített biztonsági házi- 
rend sablonok használatára, de ha ez nem felel meg az igénye- 
inknek, mi magunk is kialakíthatunk egy házirendet, majd sab- 
lonként lementve más adminisztrációs egységekben (tartomá- 
nyokban) érvényre juttathatjuk őket. Az operációs rendszer 
nemcsak arra képes, hogy bizonyos beállításokat érvényesít- 


sen, hanem arra is, hogy a létrejött beállításokat 
összehasonlítsa egy elmentett sablonnal. Ezáltal 
gyors, alapszintű biztonsági felülvizsgálatot végezhe- 
tünk el. Ha valaki megváltoztatta a biztonsági házi- 
rendet, az nagyon gyorsan kiderül. Az eredmény is- 
meretében dönthetünk arról, miképp kívánunk beavatkozni, 
hogy a feltárt biztonsági rést eltávolítsuk. 
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A hitelesítési rendszer 


A Windows 2000 hálózati operációs rendszer, amely remekül 
elvégez számos hálózati infrastrukturális feladatot, többek kö- 
zött a felhasználók és egyéb objektumok azonosítását, hitelesí- 
tését. Egy jó hitelesítési rendszernek az alábbi tulajdonságok- 
kal kell rendelkeznie: 


1. A felhasználót vagy bármely objektumot, amely ezt igényli, 
egyértelműen legyen képes azonosítani. 

2. A hitelesítéshez szükséges információkat biztonságosan 
tudja tárolni. 

3. A hálózaton áthaladó adatokat megfelelő titkosítással 
védje. 

4. A legbiztonságosabb hitelesítést is bármely hálózati kap- 
csolaton keresztül képes legyen elvégezni. 


A Windows 2000 csak részben felel meg a fenti elvárásoknak. 
Az egyértelmű azonosítás rendszertervezési kérdés. Ez a ter- 
mékben elvileg megoldott. A nem azonosítható felhasználók 
hozzáférése elutasítható, vagy egy ún. anonymous felhaszná- 
lói fiókhoz rendelhető. Bármelyik esetet választjuk, a kapcso- 
lat nyomon követhető. Az anonymous felhasználó ellentéte az 
sauthenticated users", vagyis mindazon objektumok halmaza, 
amelyeket be lehet azonosítani. Szükség esetén erre a körre 
korlátozhatjuk a hozzáférést. Sajnos, kompatibilitási okokból 
azokban a hálózatokban, ahol nem csak Windows 2000 rend- 
szerrel működő állomások találhatók, jelszóváltáskor szükség 
lehet azonosítás nélkül felépített csatornára is (null session). 
Ez egy implementációs hiba, amely a Windows NT 4.0 és ko- 
rábbi verziók sajátossága. A Windows 2000 kénytelen min- 
daddig biztosítani ezt a kapcsolatot, ameddig a korábbi verzi- 
ók el nem tűnnek a szervezet informatikai infrastruktúrájából. 
A Windows 2000 négyféle hitelesítési protokollt használ, szin- 
tén kompatibilitási okok miatt. Ezek — erősségi sorrendben — a 
következők: LANMAN, NTLM, NTLMv2, Kerberos. Az első 
szabványt használják a Win9x és korábbi rendszerek. Win- 
dows NT 4.0 SP3-ig bezárólag az érvényes módszer az NTLM 
azonosítás. Az NTASP4 verziónál újabbak, valamint az Active 
Directory Client kiegészítő szoftverrel ellátott Win9x rendsze- 
rek képesek NTLMv2 típusú hitelesítésre. A legfejlettebb, Ker- 
beros alapú azonosítást a Windows 2000 és a Windows XP 
rendszerek használják. A Kerberos egy újabb példa, hogy a 
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Microsoft internetes szabványokat implementál a sa- 
ját fejlesztései helyett. Kerberos hitelesítésre képesek 
a Unix rendszerek is, így a két eltérő platform között 
is létre lehet hozni , single sign on" eljárásrendet. 

A Kerberos hitelesítési módszernek — számos más 
erénye mellett — van egy hallatlan fontos tulajdonsága, amely 
az NTLM fölé emeli, ez a hitelesítési jegyek továbbítása. A 
mai elosztott környezetben egyetlen szolgáltatást több szerver 
nyújt. Általában van egy (tipikusan webalapú) felületet adó 
előtérbeli kiszolgáló (front-end server), és egy adatkezelést 
biztosító háttér kiszolgáló (back-end server). Az ügyfél az elő- 
térben lévő szerverrel kommunikál, de a háttérben tárolt ada- 
tokra van szüksége. Ilyenkor a front-end szervernek át kell ad- 
nia a háttérkiszolgálónak a felhasználót azonosító adatokat. 
Csakhogy az NTLM , jegy" nem továbbítható. Minden egyes 
hitelesítést a felhasználónak kell kezdeményeznie. Kerberos 
esetén a Kerberos jegyek továbbíthatók, így a hitelesítési eljá- 
rást csak egyszer kell elvégezni. A Kerberos tehát nemcsak 
biztonsági, de skálázhatósági szempontból is szerencsés vá- 
lasztás. 


A felhasználó ma még leginkább úgy találkozik a hitelesítő 
rendszerrel, hogy meg kell adnia a nevét, a jelszavát, esetleg 
azt a tartományt, amelybe be kell jelentkeznie. A legtöbb in- 
formatikai rendszerben elegendő a biztonságnak az a foka, 
amikor ,tudok valamit" (ti. egy jelszót). Egy magasabb bizton- 
sági szintet jelent, amikor már ,tudok valamit és birtokolok 
valami mást". A mindennapi megfelelője ennek a kívánalom- 
nak az intelligens kártyás azonosítás. A birtoklás a kártyára vo- 
natkozik, a tudás pedig arra a PIN kódra, amelyet a kártya el- 
helyezése után kell megadni. 

A korábban már említett moduláris hitelesítő rendszernek kö- 
szönhetően egyszerű, dokumentált mód nyílt arra, hogy a jel- 
szavas azonosítást kártyásra lehessen cserélni. A beléptető 
rendszer szorosan integrált a Windows 2000-ben kidolgozott 
nyilvános kulcsos architektúrával, erről még bővebben szó- 
lunk. 

A hitelesítés témaköréhez tartozik az úgynevezett másodlagos 
belépés (secondary logon) szolgáltatás. 
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Melyik felhasználói fiók használatával akarja futtatni a 
programot? 


O Jelenlegi felhasználó (MaLYlepenyet) 
(v]A számítógép és az adatok védelme jogosulatlan 
programtevékenységek ellen. 


Ez a funkció képes megakadályozni, hogy számítógépes vírusok kárt 
okozzanak a számítógépben vagy a személyes adatokban, de 
kijelölése azzal ís járhat, hogy esetleg a program nem működik 
megfelelően, 
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Amint már említettük, minden programkód egy meghatározott 
kontextusban fut, az őt indító objektumtól (felhasználótól, szá- 
mitógéptől) örökölve azt. A kontextus itt egyfajta engedély- 
rendszert, jogosultságrendszert jelent. A másodlagos belépés 
szolgáltatás lehetővé teszi, hogy az alkalmazás indítása előtt 
meghatározzunk egy, a sajátunktól eltérő kontextust. A szolgál- 
tatás egy valós biztonsági problémát igyekszik megoldani. Ál- 
talános gyakorlat, hogy a széles jogkörrel rendelkező felhasz- 
nálók (a rendszergazdák) mindenféle tevékenységükhöz 
ugyanazt a fiókot használják. Ez kényelmes, ugyanakkor ve- 
szélyezteti a rendszer biztonságát, 
mert a makrovírusok, trójai jellegű 
programok, internetes férgek kihasz- 
nálhatják az erős jogokat a károkozás- 
ra. Célszerű lenne, ha mindenki korlá- 
Kerberos alapú azOn0-  tozott jogkörrel dolgozna, s csak a 

rendszeradminisztrációs célokat szol- 


A legfejlettebb, 


sítást a [/jndows gáló alkalmazásokat indítaná admi- 
nisztrátori jogkörrel. A másodlagos 
2000 és a Windows belépés épp ezt teszi lehetővé. Megfe- 
lelő eljárásrenddel szabályozható, 
KP rendszerek hogy a rendszergazdák csak a szüksé- 
ges tevékenységekhez és csak a meg- 
használják. felelő alkalmazásokhoz használják jo- 


gosultságaikat. 

A sokféle hitelesítési mód összecsiszo- 
lása a lehetséges bejelentkezési helyzetekkel nem tökéletes. Bár 
egy Windows 2000 rendszerben lehetséges kártyával bejelent- 
kezni RAS vagy VPN kapcsolattal is, Terminal Server szolgálta- 
tás igénybevételekor a vékony ügyfélről nem használható a kár- 
tya (az ígéretek szerint a következő verzió, a Windows 2003 Ser- 
ver már képes lesz erre). Az igény látszólag extrém, ám ez nem 
így van. A mai korszerű rendszerekben természetes kiegészítő a 
terminál szerver szolgáltatás. Ha nem valósítható meg a kártyás 
bejelentkezés, gyakorlatilag nem lehet olyan infrastruktúrát épí- 
teni, amely ,jelszómentes". A Sun Solaris rendszerek régóta ké- 
pesek a szituáció kezelésére. Az intelligens kártyák használata a 
másodlagos bejelentkezéssel sem integrált, nincs mód egy má- 
sodik kártya használatára. A jelszavakra — úgy tűnik — még soká- 
ig szükség lesz. 

A jövő hónapban a nyílt kulcsú architektúra operációs rend- 
szerbe építéséről, az Eseménynapló biztonsági funkcióiról és a 
hálózati kapcsolatok biztonságáról lesz szó. 


Lepenye Tamás, MCSE 2000 
lepenyetomal.hu 
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Az előzőekben áttekintettük az UML használatát, néhány példával illusztrálva azt. Remélhetűleg min- 
denki kedvet kapott ahhoz, hogy további munkájához UML-t használjon. A továbbiakban még jóné- 
hány olyan, informatikában is használatos formális módszert szeretnék bemutatni, amelyek szintén 


nagymértékben segíthetik mindennapos munkánkat. 


Validáció és verifikáció 

Tekintve, hogy az informatikai rendszerek jellegzetesen egyedi- 
ek, a minőségbiztosításnak nem a termék reprodukciójára, ha- 
nem magára a konstrukcióra kell koncentrálnia. A tervezés s0- 
rán a végcél egy olyan rendszer felépítése, amely bizonyítottan 
helyes szolgáltatásokat nyújt a végfelhasználó felé. E cél érdeké- 
ben egyrészt alkalmazhatunk matematikai módszereket, ame- 
lyek (az adott modell érvényességén belül) 10099 valószínűség- 
gel bizonyítják a struktúra helyességét. Másrészt tervezett teszte- 
léssel is megpróbálhatjuk megbecsülni épülő vagy már kész 
rendszerünk jóságát. Sajnos azonban a legalaposabb tesztelés 
sem képes a teljes problématér átvizsgálására, ezért sohasem ad- 
hat 10090-os bizonyosságot rendszerünk helyes működéséről. 
A vizsgálat során két kérdéskört kell alaposan végigjárnunk: a 
megrendelő igényeinek megfelelő, jó rendszert építünk-e (vali- 
dáció), illetve a fejlesztés során kapott különböző mélységű 
modellek ekvivalensek-e, azaz jól építjük-e a rendszert (verifi- 
káció). 

Tegyük fel, hogy biztosak lehetünk abban, hogy a kiinduló spe- 
cifikációnk teljes (az egész problémateret lefedi), és az összes 
megrendelői kívánalmat teljesíti. Ebben az esetben természete- 
sen elég a tisztán verifikációs megközelítés, azaz a specifikáció 
és az implementációs modellek ekvivalenciájának bizonyítása. 
A valós életben azonban gyakran előfordul, hogy a fenti felté- 
telek nem teljesülnek, a rendszer biztonságkritikus, vagy a fel- 
használt eszközkészlet által nem garantált tulajdonságok ellen- 
őrzése elkerülhetetlen (pl. holtpontmentesség), a validációt 
sem kerülhetjük el. 

A specifikáció teljességének ellenőrzése már önmagában is 
kreativitást igénylő feladat, hiszen bonyolultabb rendszerek re- 
akcióit nemcsak az adott esetben funkcionálisan értelmes ese- 
tekre kell specifikálni, hanem minden elképzelhető (és el sem 
képzelhető) bemeneti szekvenciára is. (Lásd Ping Of Death — a 
szerk.) 


Modellalkotás és a modell ellenőrzése 


A fejlesztés első lépéseként (mint azt már korábban is említet- 
tem) a felhasználó igényeinek megfelelő rendszer egy véges 
modelljét kell megalkotnunk. Az informatikai modell a számí- 
tógépben tárolható adatszerkezetek, adatstruktúrák és az eze- 
ket kezelő, átalakító, ezekből információkat lekérdező algorit- 
musok összessége, rendszere. A modellalkotás egy absztrakci- 
ós folyamat, amelynek során egyrészt elhagyjuk a feladat 
szempontjából lényegtelen jellemzőket, másrészt pontosítjuk 
és formalizáljuk a lényegeseket, állandóan szem előtt tartva a 
feladatot majd megoldó eszköz (jelen esetben egy számítógé- 
pes hardver-szoftver környezet) tulajdonságait és képességeit. 


Egy bonyolultabb probléma megoldása közben tapasztalhatjuk 
azt is, hogy a modell két komponense nem független, az 
adatstruktúra megválasztása befolyásolja az algoritmus megvá- 
lasztását és ez fordítva is igaz. Ugyanaz az algoritmus, amely 
hatékony egyfajta adatstruktúrával, nagyon rossz hatásfokú le- 
het egy másikkal. Ezért a gyakorlati tervezés általában egy ite- 

ratív, javító, módosító lépéseket is tar- 

talmazó folyamat. 

A modellellenőrzés során a rendszer 


A modellalkotás egy . egy korábban megalkotott modelljé- 
. ről bizonyítjuk be, hogy teljesülnek-e 
absztrakciós folya: rá a kívánt tulajdonságok. 


mat, amelynek során A modellellenőrzés olyan plusz elő- 
nyökkel rendelkezik, amelyek már a 
fejlesztés korai, specifikációs szaka- 
szában is megjelennek. Ideális eset- 
a feladat szempontjá- ben a modell határozza meg a de- 
signt, a szoftvert automatikus kódge- 
nerálással készítjük, a validációt pe- 
dig modellellenőrzéssel. E technikák 
hatékony alkalmazásához azonban 
tisztában kell lennünk az alkalmazha- 
tó és alkalmazandó formális módsze- 
rekkel, illetve gyakorlatot kell szerez- 


egyrészt elhagyjuk 


ból lényegtelen 
jellemzőket, más- 


részt pontosítjuk és 


formalizáljuk nünk az eszközök és technológiák te- 
E rületén is. 
a lényegeseket. A modell végessége elvileg garantál- 


ja, hogy az algoritmus futása előbb- 

utóbb véget ér, azonban a gyakorlati 
életben általában olyan hatalmas állapotterek jönnek létre, 
amelyek teljes, kimerítő bejárása reménytelen, esélytelen vál- 
lalkozás. 
A fő kihívás tehát a mérhetetlenül nagy állapotterek kezelése. 
Az utóbbi időben két gyakorlati megvalósítás terjedt el: a tem- 
porális modellellenőrzés, illetve az automaták formájában tör- 
ténő specifikáció. 
Az előbbi alapvetően a temporális logikára épít, és a rendsze- 
reket mint véges állapotú rendszereket modellezi. A temporá- 
lis logika (amelyet már az ókori görögök, többek között Arisz- 
totelész is elkezdtek tanulmányozni) az események időbeli ta- 
nulmányozására szolgál. A modális logika egy változata, ahol 
az operátorokat arra használják, hogy a tények igazságának 
idejét jelöljék meg. Temporális logikában például ilyen állítá- 
sokat fogalmazhatunk meg: ,p a jövőben mindig, minden pil- 
lanatban igaz lesz", ,p a jövőben valamikor igaz lesz" stb. 
Egy másik megközelítés a rendszert véges automaták formájá- 
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ban írja le. Az automata ugyanúgy matematikai mo- 
dell, mint a temporális logika, vagy bármely más for- 
malizmus, azonban rendelkezik azzal az óriási 
előnnyel, hogy már ránézésre is sokminden leolvas- 
ható belőle (gondoljunk csak arra például, hogy egy 
beszédes UML ábra mennyivel gyorsabban, mennyivel több 
dolgot elárul, mint egy több oldalas magyarázkodás, amely rá- 
adásul sok esetben még félre is értelmezhető). 

Az automata mindig valamilyen meghatározott állapotban van 
(például az UML sorozatban szerepelt biliárd input interfészé- 
nek állapotai: Letiltott, Engedélyezett). Ezen állapotok közül 
mindig egy, és csakis egy érvényes (ekkor azt mondjuk, hogy 
az automata ebben az állapotban van). 

A fenti két megközelítés matematikai módszerekkel egymásnak 
megfeleltethető, ekvivalenssé tehető. 

A modellellenőrzési módszerek legfőbb veszélye az állapottér 
robbanása, azaz a probléma bonyolultságának növelésével az 
állapotok és állapotátmenetek száma exponenciálisan nő. Ma 
már különböző minimalizáló és redukciós eljárások segítségé- 
vel akár 10"" elérhető állapot is vizsgálható (természetesen au- 
tomatizált, gépi módszerekkel). 

Ezek az eljárások már a gyakorlatban is számos alkalommal 
bebizonyították létjogosultságukat. Egyik elhíresült példa az 
IEEE FUTUREBUS szabvány (71986), amelyet különböző formá- 
lis analíziseknek alávetve kiderült, hogy számos hibát és po- 
tenciális kétértelműséget tartalmaz. Sőt, a későbbiekben időa- 
nalízissel kibővített módszer még további hibákat is felfedett. 
Ez volt az első olyan eset, amikor egy nemzetközi szabványról 
matematikai módszerekkel sikerült bebizonyítani, hogy hibás. 


Lássunk most egy konkrét példát. Képzeljünk el egy épületet, 
ahova liftet szeretnénk építeni. A lift alapesetben nyugalmi ál- 
lapotban van valamelyik emeleten (Idle). Ha utasítás érkezik, 
ajtaja becsukódik, és a lift elindul a megfelelő irányba. Ha me- 
net közben olyan közbülső emeletre ér, ahonnan szintén hív- 
ták, akkor ott is megáll. Ennek az egyszerűsített modellnek az 
állapotautomatája látható az alábbi ábrán, háromszintes épü- 
letet feltételezve (földszint plusz két emelet). 






2 emeletre ér —pp- Ajtót nyit 2 —j Ajtót zár2 - 
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1. emeletre ér — Ajtót nyiti — Ajtót zár 1 
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ka 


Földszintre ér — Ajtót nyit 0 — Ajtót zár 0 








E Kétemeletes épület liftautomatája 


Induljunk ki az Idle 0 állapotból, a lift tehát a földszinten vá- 
rakozik. Amint utasítást kap arra, hogy elinduljon (akár beszáll 
valaki, akár másik emeletre elhívják), bezárja az ajtót (Aj- 
tót zár 0), elindul, majd az 1. emeletre ér. Amennyiben ide 
hívták/küldték, megáll és kinyitja az ajtót (Ajtót nyit 1), ellen- 
kező esetben folytatja útját a 2. emeletre. 

Ha az 1. emeleten kinyílik a liftajtó, utána két eset lehetséges. 
Vagy van újabb menetutasítás, és a lift ajtózárás után tovább- 
halad (Ajtót zár 1), vagy nyugalmi állapotba kerül az 1. eme- 
leten (Idle 1). A nyugalmi állapotból a földszinthez hasonló 
módon billenthető ki, működése innen kezdve az eddig leír- 
takkal ekvivalens. 


De vajon mit mondhatunk erről a rendszerről a temporális lo- 
gika nyelvén? Először is tisztázzuk, milyen operátorokat hasz- 
nálhatunk az elemi temporális kifejezésekben: 


Temporális operátor — Az operátor jelentése 








Fp Valamikor p 
(p valamikor a jövőben igaz lesz) 
Gp Mindig p (p mindig igaz) 
Xp Következő p 
k . (pa következő pillanatban igaz lesz) 
pUg p amíg g 


(p igaz, amíg g igaz nem lesz) 





Jelenlegi állapot ! Jövőbeli állapotok 


"0—O— DO 
Tá 
"OO —O—O— 








Temporális operátorok jelentése 


Lássunk tehát néhány, a liftünkre vonatkozó, temporális logiká- 
ban megfogalmazott állítást: 





Temporális kifejezés 


A kifejezés jelentése 

Mindig igaz, hogy ha valamikor az 
első emeleten kinyílik az ajtó, 

a következő állapot az ajtó bezárá- 


G((Ajtót nyit 12 
(xX(Ajtót zár 1)V 





X(Idle 1)) 

sa, vagy nyugalom lesz. 

Mindig igaz, hogy ha a földszinten 
G(Fildle.0)-2 valamikor nyugalmi állapotba kerü- 


lünk, ott is maradunk egészen ad- 
dig, amíg az ajtó bezárására (és az 
indulásra) nem kapunk utasítást. 


(Idle OJU(Ajtót zár 0)) 





Miért is jó mindez? Először is ily módon a rendszerünk tulaj- 
donságait, követelményeit implementációfüggetlen módon ír- 
hatjuk le; másrészt olyan rendszereket is vizsgálhatunk a tem- 
porális logika segítségével, amelyek be- és kimenő adatainak 


tr. § 1 


kapcsolata nem adható meg egyszerű transzformációként, ha- 
nem az időtényező is lényegi szempont (ilyenek például a fo- 
lyamatos működésű, reaktív rendszerek, az operációs rendsze- 
rek stb.). 


Egy újabb technológia: a Petri-hálók 


A Petri-hálók egyidejűleg nyújtanak grafikus és matematikai 
reprezentációt 

konkurens 

aszinkron 

elosztott 

párhuzamos 

nemdeterminisztikus és/vagy 

sztochasztikus 

rendszerek modellezésére. Mielőtt tovább borzolnám a kedé- 
lyeket, lássuk, mit is jelentenek pontosan a fenti jelzők. 

Egy rendszer konkurens, ha benne egyidejűleg működő, önál- 
ló egységek kommunikálnak egymással úgy, hogy ezen egysé- 
gek egymáshoz képest tetszőleges működési fázisban vannak. 
Aszinkronnak nevezzük az eseményvezérelt rendszereket, 
elosztottnak pedig azokat, amelyeknél az egyes rendszerele- 
mek között funkcionális tagolódás van, azaz valamilyen meg- 
egyezés arról, ki milyen feladatot lásson el a teljes és hatékony 
működés érdekében. A párhuzamos rendszerek nagyon hason- 
lítanak a konkurensekre, lényeges különbség azonban, hogy 
párhuzamos esetben a rendszerelemek között szoros szinkro- 
nizáció áll fenn (konkurens rendszereknél erre semmilyen 
megkötés nincs). 

Ha egy rendszer nemdeterminisztikus, az azt jelenti, hogy egy- 
egy adott állapotából nem egyértelmű, melyik állapot lesz a 
következő. Általában adatfüggő, hogy hova lépünk tovább, 
azonban előfordulhat, hogy a működési módot véletlennel 
modellezzük. 


B88BHBB8 


C.A. Petri a 60-as évek elején publikálta a róla elnevezett 
módszert. 

Fő jellegzetessége, hogy mindent struktúrával fejez ki: a ve- 
zérlést és az adatszerkezetet egyaránt. Ennek a megközelítés- 
nek egyik fő előnye, hogy minden más ábrázolásmód kiterít- 
hető Petri-hálóvá, ugyanakkor már egyszerű feladatok leírása 
is hatalmas hálót eredményez. Összességében azonban el- 
mondható, hogy a kiforrott matematikai háttér miatt ez a le- 
írásmód rendkívül hatékony eszköz lehet rendszerek analízi- 
sére, ha a rendszer modelljét valamely kompaktabb modelle- 
zésből automatikusan származtatjuk. 

Lássuk most, hogyan épülnek fel a Petri-hálók! Legyen N egy 
súlyozott, irányított, páros gráf. Páros gráfról lévén szó, a cso- 
mópontokat két csoportba soroljuk: helyekről és tranzíciókról 
beszélhetünk. A gráf élei minden esetben úgy futnak, hogy 
vagy egy élből kiindulva egy tranzícióban végződnek, vagy 
tranzícióból indulva helyben végződnek. Minden élhez ren- 
delhetünk egy pozitív egész értéket, amelyet az él súlyának 
nevezünk, és egy k súlyú él ekvivalensnek tekinthető k darab 
1 súlyú éllel. (A jelöletlen élek egyszeres súlyokat jelentenek.) 
Egy-egy hely állapotát tokenekkel jelölhetjük, a hálózat 
állapotát pedig az összes hely pillanatnyi tokeneloszlása mu- 
tatja. 

Speciális csomópont a forrás- és a nyelő tranzíció. A forrásnak 
nincs bemenete, és mindig képes tüzelni (lásd később), a nye- 
lő tranzíciónak pedig nincs kimenete, így a tüzelés során a 
hozzá érkező tokeneket , elnyeli". 

Lássunk egy egyszerű példát, hogy minden egyértelmű legyen: 





E Egy egyszerű Petri-háló 


A fenti ábrán egy egyszerű Petri-háló kezdeti állapotát (token- 
eloszlását) láthatjuk: A P1 állapotban 3, a P2-ben 1, P3-ban 0 
token van. AT1 tranzíciónak két bemenő (P1-ből és P2-ből), és 
két kimenő (P2-be és P3-ba) éle van. Két élnek van 1-től külön- 
böző súlya: a PIT2 él 2, a T2P1 él 3 súlyú. 


Mit is jelent mindez? Petri-hálók esetében állapotátmenet he- 
lyett tüzelésről beszélünk: ez az a folyamat, amely során a to- 
kenek ide-oda vándorolnak a hálón belül. Egy tranzíció akkor 
tüzelhet, ha az összes bemenő éléhez csatlakozó helyen van 
legalább annyi token, amennyi az adott él súlya. A fenti példá- 
ban T1 tüzelhet, mert P1-ben is, P2-ben is van 1-1 token, T2 
azonban nem, mert P1-ben van ugyan 2 token, de P3-ban 
nincs egy sem. A tüzelés során a tranzíció a bemenő éleihez 
csatlakozó helyekről (az őseitől) elveszi az élnek megfelelő 
számú tokent, a kimenő élek végpontjain álló helyekhez (utó- 
daihoz) pedig hozzáad az él súlyának megfelelő számút. A fen- 
ti ábrán például a T2 tranzíció a P3 helyről 1, a P1 helyről 2 
tokent vesz el a tüzelés során. 

Most tehát egyértelmű, hogy a következő tüzelő tranzíció a T1 
lesz, de mi történik, ha egyszerre több tranzíció is tüzelhetővé 
válik? Ebben az esetben is egyetlen tranzíció tüzel a következő 
alkalommal (a következő logikai időpillanatban), de hogy me- 
lyik, az előre teljesen kiszámíthatatlan (a Petri-háló nemdeter- 
minisztikus volta miatt). 

Lássuk, hogyan is néz ki a fenti háló a T1 tranzíció tüzelése 
után: 


3 





E A FPertri-háló a TT tranzíció tüzelése után 
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ül Jól látható, hogy most már mind a T1, mind a T2 ál- 
; eszt lapot tüzelhető. Lássuk, hogyan néz ki a háló az 
Ez egyik, illetve a másik esetben: 





I A Petri-háló a TT tranzíció újabb tüzelése után 


Ha a T1 tranzíció tüzel újra, a hálózat a fenti állapotba kerül. 
A T2 tranzíció ismét nem képes tüzelésre, és kis odafigyeléssel 
az is látható, hogy ha a T1 tranzíció még egy alkalommal tü- 
zel, akkor a PI helyen nem marad több token, a háló holtpont- 
ba (deadlock) kerül, működését nem tudja folytatni. Az esetek 
többségében ez nem engedhető meg, így különböző módsze- 
reket dolgoztak ki a Petri-hálók holtpontmentesítésére (ezekről 
a későbbiekben írok). 


3 





E A Petri háló a T2 tranzíció tüzelése után 


Ha az előző lépésben tekintett hálóban (ahol TI már tüzelt 
egyszer) a következő tüzelő tranzíció a T2 lesz, a háló a fenti 
ábrán látható állapotba kerül — amely megegyezik a kiinduló 
tokeneloszlással. 

Mindezt matematikai formalizmussal is leírhatjuk. Egy adott to- 
keneloszlást az az M vektor jelöl, amelynek dimenziója a P he- 
lyek száma (rr-I PI), elemei pedig az adott sorszámú helyen az 
adott pillanatban található tokenek száma. Az előzőekben te- 
kintett kezdeti tokeneloszlás leírása tehát ily módon (7r—3): 


Moz 1 
o 


ATI tranzíció tüzelése után: 
MiysjA 


Hasonlóan írhatók fel az újabb tüzelések utáni állapotok toke- 
neloszlásai is. 


A logikai idő 

Fentebb említettem egy érdekes fogalmat, a logikai időt. Fizi- 
kai időnek nevezem azt, amit óránkkal, a napszakok változá- 
sával stb. mérhetünk, tehát ami a rendszertől független, objek- 
tív időskálán szemléltethető (többnyire szabályosan periodi- 
kus). 

A logikai idő a rendszer mőködésétől függ, viszonyítási pontjai 
a bekövetkezett események, Petri-hálók esetében a tüzelések. 
Szemléletesen a [T1, T2, T1, T1] tüzelési szekvencia a fizikai 
és a logikai időben így néz ki: 


1 ő a 4 s 6 z. 


o 9 5 
o 1 2 3 
Logikai idő FF — e ———j 


Tüzelés: TI T2 Ti Ti 


E Tüzelési szekvencia a fizikai és a logikai időben 


A példa szerint az idő mérése az első tüzeléskor indul (T7). A 
T2 tranzíció tüzelése logikai és fizikai időpontja (véletlenül) 
egyaránt az 1 időpillanat. A harmadik tüzelés (T7) a fizikai 5, a 
logikai 2 időben, míg a negyedik (TT) a fizikai 7 és a logika 3 
időpontban történik. 

Ezáltal egy olyan, implicit időfogalmat kacsolunk rendszerünk- 
höz, amelyben egy engedélyezett tranzíció tüzelése a [0, co) in- 
tervallumban bárhol megtörténhet (fire-at-will). 


A nemdeterminisztikus működés kiküszöbölése 


Ez a nemdeterminisztikus működés azonban nem mindig en- 
gedhető meg. Ennek kiküszöbölésére különböző korlátozáso- 
kat vezethetünk be rendszerünkben. 

Tekintsük elsőként az alábbi Petri-hálót, amely nyolcas szám- 
lálót hivatott modellezni: 


FEST 


E3 Nyolcas számláló modellezése Petri-hálóval 


Mindez úgy működik, hogy egyetlen token kering a rendszer- 
ben, amelynek minden ugrása a számláló egy ugrását jelenti: 
kezdetben a token a PO helyen van. A következő tüzeléskor át- 
kerül az P1-es állapotba, majd a P2-be stb. A kör végén a P7- 
es helyrők ismét a PO-ba ugrunk, és kezdődik az egész szám- 
lálás elölről. 

Igen ám, de a tüzelésekhez kötött logikai idő semmit nem 
mond arról, hogy fizikailag mikor következik be a következő 
ugrás, mi pedig szeretjük a határidőket, szeretjük tudni, mi mi- 
kor következik be. 

Próbáljunk meg órajelet bevezetni. Első megközelítésben ez 
egyetlen forrás-tranzíciót jelent, amely tokeneket juttat a rend- 
szerbe az alábbi módon: 


Pi 


Pn N / P2 
Ta8S 


Pad 


VT P5 N . 


B Órajel bevezetése a nyolcas számlálóba 


A CLK bizonyos időközönként tokent juttat a rendszerbe. Az 
újabb élek felvételével a tranzíciók már csak akkor tüzelhet- 


nek, ha a középső állapotban van token, azaz , ütött ] ] 
az óra". Et 
Igen ám, de még ha van is órajel-tokenünk, akkor —— mg 


sem garantált, hogy a soron következő tranzíció tüzel 

a következő óraütés előtt. Sajnos a Petri-hálók sajá- 

tosságai miatt ezt nem tudjuk garantálni, azonban megkerülve 
egy kicsit a problémát, azt igen, hogy az óra ne üthessen ad- 
dig, amíg az előző órajelre nem történt ugrás a számlálóban. 
(Ha a hegy nem megy Mohamedhez...) 

Korlátozzuk tehát a középső állapot kapacitását egyetlen to- 
kenre (ezt jelöli a beleírt 1-es). Ez azt jelenti, hogy azon a he- 
lyen maximum 1 token lehet egyszerre, tehát bemenő tranzí- 
ció nem tüzelhet, amíg a tüzelés túllépné a kapacitáskorlátot. 
Így ha esetünkben egyszer már ütött az óra, tehát van órajel-to- 
ken a rendszerben, akkor mindaddig nem üthet újra az óra, 
amíg ez el nem tűnik, azaz amíg a számláló nem lép egyet. Így 
biztosíthatjuk azt, hogy minden órajelre egyet és pontosan 
egyet lépjen a számlálónk. 


Másik módszer, hogy kapacitáskorlát helyett tiltó éleket ve- 
szünk fel a hálóba. A tiltó él azt jelöli, hogy a tranzíció ne tü- 


zeljen, amíg az adott feltétel teljesül. Az alábbi ábrán például 
addig nem tüzel a tranzíció, amíg a P2 helyen van token: 


Pi 


I 
P2 


P3 


E Tiltó él a Petri-hálóban 


Ha a tiltó élhez egy k súlyt is rendelünk, az azt jelenti, hogy ha 
az él bemeneti helyén az adott k számú, vagy annál több to- 
ken van, akkor a tranzíció tiltott, ha k-nál kevesebb token sze- 
repel a helyen, akkor a tranzíció engedélyezett. 

Ezzel a módszerrel azt köthetjük tehát ki, hogy mindaddig nem 
jöhet óraütés, amíg van token a megfelelő helyen. 


Ám ez még mindig nem elég... A kapacitáskorlátok kiküszöbö- 
léséről, szimulációs algoritmusokról és egyéb ínyencségekről a 
következő számban írok majd. 


Molnár Ágnes 
agnes.molnarOt-systems.com 
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NETALADEITUR MEJTERÜRÉUSUK 


2003. Tavaszi program 


A tavaszi előadások vendégelőadói értékes ajándékokkal is meglepik a kedves résztvevőket! 
Keresse a tech.net magazinban a kedvezményes részvételre jogosító jegyet! 


2003. március 27. 13:45 - 18:00 


13:35 — 14:00 


14:00 — 15:00 
z 
A 

15:00 — 16:00 


16:00 -— 16:20 
16:20 — 17:20 


17:20 — 18:00 


2003. május 





Regisztráció 
Bevezetés a hálózati forgalom elemzésébe 
Minél összetettebb egy vállalati hálózat, minél többféle szolgáltatást futtatunk, annál furcsább hibajelen- 
ségeknek lehetünk időnként tanúi. A hálózati forgalom elemzésével olyan hibák felderítésére is lehetőség 
nyílik, amelyekről semmit sem mond az Eseménynapló! 
(Fóti Marcell) 
(Kapcsolódó tanfolyamaink: NetMon Workshop, TCP/IP Workshop) 


A nyílt kulcsú technológia építőkockái 
A digitális aláírási törvény megjelenésével egyre több vállalat fordul érdeklődéssel a nyílt kulcsú techno- 
lógiák felé. Mi kell ahhoz, hogy elérhetővé váljon számunkra a PKI adta sok-sok lehetőség? 
(Vendégelőadó: NetLock Kft.) 
(Kapcsolódó tanfolyamaink: PKI Workshop) 


Kávészünet 


Nyílt kulcsú architektúra a Windowsban 
A PKI felhasználási területei a titkosított hálózati kommunikációtól a digitális aláíráson keresztül a felhasz- 
náló-azonosításig terjednek. Kiszolgálóoldalon többek között a RAS, VPN, IPSec, és IIS, felhasználói 
oldalon a Smart Card Logon, dokumentumok aláírása, S/MIME a témaválaszték. A műsorváltoztatás jogát 
az újonnan megjelenő szolgáltatások miatt fenntartjuk! 
(Fülöp Miklós) 
(Kapcsolódó tanfolyamaink: 2150 - Windowsos hálózatok biztonsága, 2159, ISA Server) 
Gyakorlat: Felhasználói és kiszolgálóoldali PKI-gyakorlatok 
Hiteles NetLock tanúsítványpár elektronikus aláíráshoz és titkosításhoz. A kulcstároló 
eszközök a helyszínen megvásárolhatók. 


29. 13:45 —- 18:00 








13:35 — 14:00 
14:00 — 15:00 


15:00 — 16:00 


16:00 — 16:20 
16:20 — 17:20 
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Regisztráció 

Az elektronikus levelezés védelmének lehetőségei Exchange Serveren 

Az elektronikus levelezés áldás és átok egyben. A veszélyes leveleket nem szabad a felhasználókig eljuttat- 
ni. Ennek eszköze lehet az Outlook-ügyfelekhez készített központi korlátozóeszköz, vagy egy víruskereső. 


(Fóti Marcell) 
(Kapcsolódó tanfolyamaink: 1572 - Exchange Server üzemeltetése) 


SOAP (Előadó: Soczó Zsolt) 
A webszolgáltatások alapjait a SOAP-szabvány rakta le. Az előadásban áttekintjük a SOAP történelmi 
gyökerét, és az XML-technológiákon keresztül megnézzük gyakorlati felhasználását is. 
(Soczó Zsolt) 
(Kapcsolódó tanfolyamaink: .NET fejlesztési tanfolyamok) 


Kávészünet 


A Windows rendszerek támadható, és védelmi felületei 
A vírusvédelem egyik faktora nyilván a jó, friss víruskereső program. A másik faktor az okos felhasználó, 
illetve az okos rendszergazda. Ebben az előadásban megismerkedünk a vírusok által használt támadási 
trükkökkel, így soha többé nem fogunk Administratorként levelezni... 
(Vendégelőadó: VirusBuster Kft.) 

(Kapcsolódó tanfolyamaink: 2150 - Windowsos hálózatok biztonsága, 2159, ISA Server) 

Gyakorlat: Felhasználói és kiszolgálóoldali PKI-gyakorlatok 
Virus Buster Personal Edition, 1 éves előfizetéssel 


A MesterOrzusok helyszíne: NetAcademia Kft., Budapest, Andrássy út 62. 
Jelentkezés: http://www.netacademia.net/mesterg 
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tech.net magazin 
előfizetési szelvény 


Címzett: NetAcademia KÉt. 
Faxszám: (1) 472-1215 






ja 


http://technet.netacademia.net/subs/szamrend.asp 9 e-mail: terjesztesonetacademia. net e fax: (1) 472-1215 


Előfizetem a tech.net magazint: 
ÖL EŐÉS példányban egy évre (14.784 Ft) 
SRE NÉG4Ő példányban fél évre (7.392 F0. 


A fizetés módja: LI csekkel LI átutalással 
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MesterOrzus megrendelőlap 


Címzett: NetAcademia Kft. ax 


Faxszám: (1) 472-1215 





A 2003 első félévében megrendezésre kerülő MesterOrzus konferenciák: 


2003. március 27. 13:45 - 18:00 5000 Ft-HÁFA/fő 
Fóti Marcell: Bevezetés a hálózati forgalom elemzésébe 
NetLock Kft. vendégelőadó: A nyílt kulcsú technológia építőkockái 
Fülöp Miklós: Nyílt kulcsú architektúra a Windowsban 


Gyakorlat: Felhasználói és kiszolgálóoldali PKI-gyakorlatok 


Ajándék: Hiteles NetLock tanúsítványpár elektronikus aláíráshoz és titkosításhoz. A kulcstároló eszközök a helyszínen 
megvásárolhatók. 


2003. május 29. 13:45 - 18:00 5000 Ft--ÁFA/fő 
Fóti Marcell: Az elektronikus levelezés védelmének lehetőségei Exchange Serveren 
Soczó Zsolt: SOAP 


VirusBuster Kft. vendégelőadó: A Windows rendszerek támadható, és védelmi felületei 
Gyakorlat: Felhasználói és kiszolgálóoldali PKI-gyakorlatok 


Ajándék: Virus Buster Personal Edition, 1 éves előfizetéssel 


A konferenciákkal kapcsolatban a változtatás jogát fenntartjuk! 





Megrendelem a MesterOrzus konferenciákon való részvételt az alábbiak szerint: 


2003. MÁárCÍUS 275. 0 sszassásséssési fő 

ZOO3L MÁJUS ZT, 0 sássszagésáésss fő 
Megrendelő Neve (kapcsolattalójó sazs ene vsksrasesma ke ö pszt dks e talk ísttáve éz ő 6 a érv e ÜELE VÉLE 
CÉH NEVE s s siess szé vétszerás érését áréráléne ő érézá a öjéjézerére ő sralésé elé é éb óda özv éabégnérk a élárb als ene érő 


Bővebb információt a http://www.netacademia.net/mesterg honlapon talál, illetve a következő elérhetőségeinken kérhet: 
Tel.: 472-1214 Fax: 472-1215 infoxnetacademia.net 


VA ga -ÉJE 


u Egyedülálló lehetőség a felhasználóknak 


bárki saját személyes címlistát készíthet a letöltött adatok felhasználásával 


un Speciális keresési opciókkal 





Több mint 90 000 cég, vállalkozás adatai az 
ország egész területéről, keresési lehetőségek: 
név, cím, telefonszám, tevékenység és kerület alapján 
A keresett cég telephelye megtekinthető térképen is 
(Budapest, Győr, Miskolc, Pécs és Szeged) 
angol és magyar nyelven egyaránt. 


www.superpages.hu 





R Te 4.99 fi £ is öt h 4. 86-i té fé d a öle 
/an-e ,elet a hagyományos Microsofív- 
tanfolyamok után? 


A NetAcademia egyedi, hiánypótló Workshop-tanfolyamait azok számára készítettük, akik 











e Nem elégszenek meg a hivatalos tananyagok által nyújtott információval (1 téma — 1 óra) 
e Először gondolkodnak, tapasztalatot szereznek és csak azután cselekszenek 
e Szeretik átlátni a rendszerek működését, a miérteket 
e A legújabb technológiák ismeretében készülnek a jövőre 
e Nem gondolják azt, hogy amit nem látnak, az nem is létezik 
Kód Témakör 
. AD Active Directory mélyvíz ee 
DIS Katasztrófaelhárítás — KSZN Figyelt 
NM Hálózatmonitorozás 
jő PKI Elektronikus aláírás és titkosítás K K 
SCR Seripting KN 
SETUP Felügyelet nélküli telepítés 
SECU . Betörésvédelem o 
TCP/IP TCP/IP-alapú vállalati hálózatok kiépítése j je 
WMI Windows Management Instrumentation 
XP Windows XP nagyvállalati környezetben 


Részletes tematika és jelentkezés: http://www.netacademia.net 
Kérje teljeskörű, ingyenes katalógusunkat az info Dnetacademia.net címen! 





mérnök képzések 


A SZÁMALK Továbbképzés 2003-ban is tavalyi, változatlan áron kínálja hivatalos Microsoft tanfolyamaira épülő 
Microsoft rendszeradminisztrátori (MCSA), rendszermérnöki (MCSE), adatbázis-adminisztrátori (MCDBA) és 
Microsoft .NET fejlesztői (MCAD/MCSD) képzéssorozatait. A tanfolyamokat követően lehetősége van vizsgákat 
tenni Prometric vizsgaközpontunkban és megszerezni a nemzetközileg elismert oklevelek valamelyikét. 


MCSE (rendszermérnök) képzés az öt kötelező vizsgához március 3-tól 430.000 helyett már 399.000 Ft-tól!!! 
Nagy, összetett informatikai rendszereket és hálózatokat üzemeltető szakemberek képzése, akiknek feladatuk lesz Windows 2000 ala- 
pú hálózatok teljeskörű adminisztrálása és támogatása, informatikai infrastruktúrák tervezése. 


MCSA (adminisztrátor) képzés a kötelező vizsgákhoz március 3-tól 270.000 Ft helyett már 229.000 Ft-tól! 
A kisebb informatikai rendszereket és hálózatokat üzemeltető szakemberek számára ajánljuk, akiknek feladatuk lesz Windows 2000 ala- 
pú hálózatok telepítése, konfigurálása, adminisztrálása, karbantartása. 


MECDBA (adatbázis-adminisztrátor) képzés a kötelező vizsgákhoz március 3-tól 504.000 Ft helyett már 459.000 Ft-tól! 
Microsoft SOL 2000 alapú adatbázisrendszerek teljeskörű üzemeltetésével, támogatásával, karbantartásával, tervezésével és imple- 
mentálásával megbízott szakemberek részére ajánlott képzés. 


Microsoft .NET fejlesztői képzés 259 kedvezménnyel február 17-től 750.O0O Ft helyett 595.000 Ft-ért! 
Fejlesztők, programozók számára ajánlott képzés, akiknek feladatuk lesz összetett, Windows-alapú és webes alkalmazások készítése, 
fejlesztése, szolgáltatások implementálása és tervezése a Microsoft Visual Studio .NET és Microsoft .NET keretrendszerének segítségé- 
vel. Az alapoktól a haladó szintig. Párhuzamosan a Ct és Visual Basic .NET programnyelveken. 


73 " Egészítse ki tanfolyamon szerzett ismereteit, készüljön fel a hivatalos Microsoft vizsgákra a 
Microsoft Pi 1695 Microsoft Press kiadó professzionális szakkönyveinek segítségével! 


Több mint 800 féle kiadvány, kedvező árak, nagy raktárkészlet! 
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